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1  Introduction 

The  Advanced  Distributed  Learning  (ADL)  Registry  is  a  Department  of  Defense  (DoD)- 
sponsored  and  DoD-operated  service  for  registering  the  existence,  locations,  and 
descriptions  of  digital  resources  (or  objects)  developed  or  acquired  by  the  DoD  and 
intended  for  use  in  distributed  learning  (training,  education,  and  performance  and 
decision  aiding).  The  ADL  Registry  is  a  centralized  service  that  manages  the  processing, 
storage,  identification,  and  indexing  of  information  about  digital  objects  that  are  stored  in 
multiple,  independently  managed,  and  variously  located  repositories.  It  allows  local 
repositories  to  maintain  control  of  their  objects  while  sharing  their  existence  and 
information  about  them  -  called  metadata  -  with  a  wide  community  of  potential  users. 

This  document  -  Volume  2  of  a  five-document  set  -  provides  an  overview  of  the  ADL 
Registry  and  guidance  for  using  the  ADL  Registry  Web  site.  Volume  1  provides  an 
overview  of  the  ADL  Registry  initiative,  including  history,  high-level  requirements, 
design  assumptions,  and  rationale.  Volume  3  provides  detailed  technical  information 
about  the  ADL  Registry.  Volumes  4  and  5  provide  more  detail  on  the  Content  Object 
Discovery  and  Registration/Resolution  Architecture  (CORDRAtm)  and  information 
about  value-added  services  and  tools,  respectively. 

The  ADL  Registry  Web  site  resides  at 

http  ://adlregistrv.adlnet.  gov 

Additional  information  about  the  ADL  Registry  can  be  found  at 

http  ://www.adlnet.  gov/T  echnolo  gies/ adlr/ default,  aspx 

NOTE  -  This  document  uses  the  term  “digital  object”  to  refer  to  resources  that  may  be  registered 
in  the  ADL  Registry.  In  addition  to  objects  that  contain  content  for  display  to  the  learner  (content 
objects)  and  objects  with  specific  educational  and  training  goals  (learning  objects),  a  digital 
object,  as  used  here,  may  be  anything  of  value  to  the  learning  community,  such  as  a  simulation, 
mathematical  model,  teaching-strategy  algorithm,  glossary,  technical  manual,  or  style  guide.  A 
digital  object  may  also  be  a  collection  of  resources  encapsulated  in  a  package,  such  as  a  ZIP  file. 
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2  An  overview  of  the  ADL  Registry 

The  ADL  Registry  is  the  first  publiely  available  instance  of  CORDRA.  It  was  developed 
for  the  DoD  by  a  partnership  between  the  ADL  Initiative  and  the  Corporation  for 
National  Research  Initiatives®  (CNRI).  This  section  provides  an  overview  of  the  ADL 
Registry,  including  its  structure  and  functionality,  participant  roles  and  participation 
requirements,  and  an  introduction  to  the  Handle  System®  [8]^  which  supplies  unique, 
persistent  identifiers  called  handles  for  digital  objects  and  a  means  for  locating  them 
through  a  registry. 

2.1  High-level  description 

The  ADL  Registry  provides  centrally  searchable  information  -  metadata  records  -  that 
describe  digital  objects.  Each  record  provides  sufficient  detail  so  that  searchers  can  find  - 
or  discover  -  objects  according  to  specific  characteristics.  By  using  metadata  for  object 
discovery,  the  ADL  Registry’s  search  and  discovery  services  identify  relevant  objects 
more  precisely  with  fewer  irrelevant  results  than  the  text-crawling  processes  used 
elsewhere. 

After  a  digital  object  has  been  discovered,  the  ADL  Registry  allows  it  to  be  located  -  or 
resolved-  through  the  use  of  a  handle  (see  Section  2.6).  Handles  allow  objects  to  be 
found  despite  changes  in  locations  and  other  access  characteristics  likely  to  occur  over 
their  lifetime.  In  this  way,  handles  are  unlike  other  resource  locators  that  bundle  object 
locations  and  identifiers  together  and  can  lose  an  object  if  it  is  moved,  for  example,  from 
one  repository  to  another.  In  short,  the  ADL  Registry  allows  developers  to  register 
learning  assets  and  other  digital  objects  to  enable  and  facilitate  their  discovery,  location, 
and  reuse. 

As  shown  in  Figure  1,  independently  managed  object  repositories  exist  throughout  the 
DoD.  These  repositories  may  have  no  direct  affiliation  with  one  another.  Their 
implementation,  management,  usage,  and  access  policies  may  differ  widely.  ADL 
Registry  participation  does  not  impact  these  aspects  of  locally  controlled  repositories  but 
does  require  a  consistent  method  for  registering  metadata  records. 


*  The  numbers  in  brackets  correspond  to  those  in  the  bibliography  in  Appendix  A. 
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Figure  1-  Multiple  independent  object  repositories 

As  Figure  2  suggests,  the  ADL  Registry  allows  DoD  components,  approved  non-DoD 
federal  activities,  and  associated  contractors  that  operate  government-owned  repositories 
to  submit  metadata  records  about  digital  objects  that  they  create  or  acquire.  Submitting  a 
metadata  record  constitutes  registration  of  the  object  it  describes.  Metadata  records  use 
the  Institute  of  Electrical  &  Electronics  Engineers  (IEEE)  Learning  Object  Metadata 
(LOM)  format  [4],  which  is  a  standard,  internationally  recognized  model  for  storing  and 
retrieving  metadata  about  objects  used  in  learning  applications.  The  records  are  encoded 
as  Extensible  Markup  Language  (XML™)  [9]  documents. 
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Figure  2  -  Repositories  submit  metadata  about  objects 

Metadata  records  are  submitted  either  manually  through  the  ADL  Registry  Web  site  or 
automatically  using  tools  designed  to  access  a  registry  interface  mechanism  (RIM)  called 
RIM-Lite  (see  Volume  3).  Digital  objects  are  assigned  unique  identifiers.  A  single  object 
may  have  multiple  metadata  records  associated  with  it  through  its  identifier. 
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The  ADL  Registry  uses  CNRFs  Handle  System  [8]  for  identifying  digital  objects  (see 
Section  2.6).  The  ADL  Registry  accepts  the  registration  of  objects  already  identified  by 
handles,  in  which  case  those  handles  are  managed  externally  to  the  ADL  Registry  project. 
The  ADL  Registry  also  allows  registering  objects  not  currently  identified  by  handles  and 
provides  a  handle  service,  eliminating  the  need  for  organizations  to  install  and  maintain 
their  own  handle  servers. 

As  shown  in  Figure  3,  the  ADL  Registry  Web  site  lets  users  search  metadata  in  the  ADL 
Registry.  Search  results  may  resolve  directly  to  digital  objects  or  to  a  means  of  retrieval 
that  requires  local  access  and  authentication  privileges,  which  are  the  responsibility  of  the 
local  repository.  The  ADL  Registry  can,  then,  provide  global  visibility  for  an  object  while 
preserving  local  control  over  its  access. 


ADL 
Registry 
Web  Site 


ADL 

Registry 


Metadata 

Metadata 

Metadata 

Metadata 


JFCOM 


V _ / 


Figure  3  -  Metadata  about  digital  objects  may  be  searched  by  anyone 
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The  ADL  Registry  provides  a  means  for  many  independently  loeated  and  managed  object 
repositories,  each  with  its  own  local  policies  and  procedures,  to  register  information 
about  digital  objects  so  that  the  objects  can  be  discovered,  resolved,  and  accessed.  The 
ADL  Registry  is  an  improvement  over  alternative  approaches  to  search,  discovery,  and 
resolution  in  that 

•  It  allows  objects  to  be  managed  locally,  thus  creating  minimal  impact  on 
repository  policies  and  procedures. 

•  It  provides  a  robust  set  of  services,  including  the  management  of  metadata  records 
and  persistent  object  identifiers. 

•  It  is  based  on  a  scalable  architecture  that  can  support  many  separate  repositories. 

•  It  can  be  associated  -  or  federated  -  with  other  registries  over  time  to  increase  the 
depth  and  breadth  of  searches. 

•  It  allows  objects  to  be  intentionally  made  visible  by  approved  contributors  and 
more  precisely  discovered  than  other  more  general  Web  searching  strategies  that 
index  all  objects,  regardless  of  their  nature  or  quality. 

•  It  allows  objects  that  cannot  be  accessed  by  general  Web  search  engines  to  be 
available  for  search  and  discovery  while  protecting  access  to  them. 

•  It  supports  tools  and  services  for  automating  many  registration  and  maintenance 
processes  to  both  register  objects  and  keep  their  information  current. 

In  short,  the  ADL  Registry’s  architecture  and  implementation  address  the  requirements 
and  challenges  involved  in  developing  systems  intended  to  discover,  locate,  and  access 
digital  objects  in  repositories  across  a  wide  variety  of  domains. 

2.2  Participant  roies  and  descriptions 

As  shown  in  Figure  4,  the  ADL  Registry  project  involves  multiple  participants  playing 
different  roles  in  repository  and  registry  operations.  Their  roles  and  responsibilities  are 
summarized  below. 
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ADL  Registry  Personnel 


ADL  Registrar 


ADL  Help  Desk 


Figure  4  -  ADL  Registry  project  participants 


ADL  Registry  user;  Anyone  accessing  the  ADL  Registry  to  search  for  digital  objects 
using  the  ADL  Registry  Web  site  or  similar  services. 

Repository  manager;  An  individual  who  is  responsible  for  the  day-to-day  operation  and 
maintenance  of  a  repository.  Responsibilities  with  respect  to  the  ADL  Registry  include 

•  Identifying  individual  account  holders  and  verifying  their  contact  information. 

•  Ensuring  that  metadata  describing  repository  objects  is  provided  to  the  ADL 
Registry. 

•  Ensuring  that  metadata  provided  is  accurate,  complete,  and  timely. 

•  Ensuring  that  the  repository  staff  is  trained. 

Contributor  group  member;  Anyone  associated  with  a  participating  repository  and  who 
is  authorized  to  contribute  metadata  to  the  ADE  Registry.  Contributor  group  members 
can  insert,  update,  activate,  and  deactivate  metadata  records  (see  Section  5). 


7 


Manager  group  member:  A  contributor  who  has  additional  rights  to  delete,  withdraw, 
and  move  metadata  records  (see  Section  5). 

Repository  sponsor:  The  person  or  office  within  DoD  responsible  for  a  repository’s 
existenee. 

DoD  Component  Proponent:  The  person  or  offiee  within  DoD  responsible  for 
approving  a  repository’s  existence,  per  Department  of  Defense  Instruction  (DoDI) 
1322.26  paragraph  5  [2], 

ADL  Registrar:  The  ADL  offieial,  working  at  the  direction  of  DoD,  who  grants  access 
privileges  and  rights  to  the  ADL  Registry  according  to  DoD  policies.  The  ADL  Registrar 
is  responsible  for 

•  Authenticating  and  registering  repositories. 

•  Aequiring  additional  information  as  needed  and  to  determine  access  rights  for  a 
eontributor  or  manager  group  member. 

•  Creating  accounts  for  individual  participants  and  ensuring  they  are  assigned  to 
appropriate  groups. 

•  Providing  user  names  and  passwords. 

ADL  Registry  Help  Desk:  The  help  desk  is  responsible  for 

•  Providing  help  with  technical  questions  and  Web  site  issues. 

•  Assisting  in  registering  and  discovering  digital  objects. 

•  Providing  training  for  new  aeeount  holders. 

2.3  Participating  repositories 

A  participating  repository  is  a  local  system  for  storing,  maintaining,  and  aeeessing  digital 
objects  and  one  that  has  registered  to  participate  in  the  ADL  Registry  project.  While  no 
speeffic  implementation  is  assumed,  eertain  capabilities  are  required  to  participate  with 
the  ADL  Registry.  These  include 

•  A  means  to  ereate,  register,  and  maintain  metadata  reeords  in  the  ADL  Registry. 

•  A  means  to  eleetronically  access  registered  digital  objects  within  the  repository  or 
obtain  non-digital  objects. 

•  Approval  to  participate  in  the  ADL  Registry  by  the  appropriate  DoD  Component 
Proponent. 

Typieal  partieipating  repositories  are  government  owned  and  either  government  or 
contraetor  operated.  In  some  cases,  a  government-owned  repository  may  be  both  hosted 
and  operated  by  a  contraetor. 

A  participating  repository  may  be  implemented  in  any  way  as  long  as  speeffic  capabilities 
and  external  interfaces  are  provided.  At  a  minimum,  a  repository  must  be  able  to  store 
digital  objects  and  make  them  available  for  reuse,  either  by  direct  access  or  by  providing 
information  about  how  to  aecess  them.  The  repository  also  must  be  able  to  provide 
metadata  records  to  the  ADL  Registry.  ADL  places  no  requirements  on  how  objeets  are 
stored  and  represented  in  repositories. 
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The  requirement  that  a  repository  must  be  able  to  provide  metadata  reeords  suggests  that 
such  records  reside  somewhere  in  the  repository.  Although  this  is  not  a  specific 
requirement,  because  of  the  value  and  cost  of  metadata,  the  need  to  keep  such  metadata 
synchronized  with  evolving  versions  of  objects,  and  the  need  for  internal  life-cycle 
management,  it  is  assumed  that  metadata  typically  will  be  created  during  the  object 
development  process  and  stored  somewhere  in  a  repository. 

2.3.1  Repository  manager  role 

As  implied  by  Figure  5,  ADL  assumes  that  a  repository  manager  is  responsible  for  the 
operation  and  maintenance  of  a  repository.  The  repository  manager  manages  the  storage 
of  digital  objects  in  the  repository,  implements  policies  for  security,  access,  and  other 
local  business  rules,  and  is  the  primary  contact  for  repository  administration. 


Provides 
means 
to  access 
objects 


ADL  Registry 
user 


Access 
provided 
according 
to  local 
policies 


Repository  Manager  or  Designee 


Creates/obtains  digital 
objects  and  puts  them 
in  the  repository 


Creates/maintains 
metadata  about  the 
digital  objects  and  puts 
it  in  the  repository 


Digital  Objects 


Metadata  Records 


Metadata 

Metadata 

Metadata 

Metadata 

Metadata 


Registers 
object 
metadata 
records  in 
ADL  Registry 


ADL  Registry 


Uses  ADL 
Registry  Web 
site  or  RIM-Lite 
interface  to: 

-  Insert 

-  Delete 

-  Update 

-  Activate 

-  Withdraw 

-  Deactivate 
-Move 


Figure  5  -  Repository  manager  responsibilities 
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To  participate  in  the  ADL  Registry,  a  repository  manager  must  obtain  approval  from  the 
DoD  Component  Proponent  and  register  the  repository  with  the  ADL  Registry  (see 
Section  3.2).  After  the  registration  is  approved  by  the  ADL  Registrar,  the  repository 
manager  determines  who  is  allowed  to  contribute  metadata  to  the  ADL  Registry  and 
whether  they  should  be  members  of  the  contributor  group  or  the  manager  group.  The 
manager  then  registers  them  using  the  ADL  Registry  Web  site  (see  Section  3.3). 

2.3.2  Repository  contributions 

Once  a  repository  has  been  approved  and  registered,  metadata  records  may  be  contributed 
to  the  ADL  Registry.  These  contributions  must  adhere  to  the  ADL  Registry  LOM  schema 
and  be  encapsulated  in  accord  with  the  ADL  Registry  transaction  specification  (see 
Volume  3). 

As  discussed  earlier,  the  digital  object’s  location  is  part  of  the  information  provided  to  the 
ADL  Registry.  This  location  may  point  either  directly  to  the  object  or  to  a  repository 
service  that  provides  access  to  the  object.  If  local  security  and  access  policies  prevent 
direct  access  to  an  object,  the  repository  manager  is  required  to  document  how  it  may  be 
obtained,  for  example,  by  displaying  a  Web  page  with  requirements  and  contact 
information.  Although  no  specific  access  mechanism  is  required,  repository  managers 
should  provide  a  simple  automated  way  to  deliver  objects  to  ADL  Registry  searchers. 
Such  a  mechanism  may  require  approval  and  authentication  for  accessing  objects,  but  it 
should  make  objects  available  as  easily  and  automatically  as  possible. 

Digital  objects  retrieved  from  a  repository  may  be  of  any  format  or  type.  The  object’s 
metadata  record  includes  information  that  identifies  the  formats  of  its  contents.  One  form 
that  objects  may  be  stored  in  is  a  Shareable  Content  Object  Reference  Model  (SCORM®) 
package  [7].  A  SCORM  package  is  a  compressed  ZIP  file  containing  information  about 
the  organization  of  the  file’s  objects  and  all  related  files  needed  to  display  them.  Such 
packages  are  self-describing  through  the  use  of  an  internal  list  of  contents  (i.e.,  a 
manifest).  They  may  consist  of  one  simple  object  or  a  collection  of  objects  and 
supporting  fdes. 

NOTES: 

1.  When  an  object  is  registered,  several  types  of  related  Uniform  Resource  Locator  (URLs)  may 
be  provided  (see  Section  3. 1.2.1).  If  the  object  is  not  available  for  direct  download  via  an  object 
URL,  information  on  how  to  obtain  the  object  should  be  provided  via  a  contact  URL.  A 
repository  should  not  register  objects  that  cannot  be  obtained  in  some  way  that  is  under  direct 
control  of  the  repository. 

2.  The  ADL  Registry  LOM  schema  is  available  at 

http://hdl.handle.net/2000.2/adlreg-lom 
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2.3.3  What  to  register 

DoDI  1322.26  [2]  requires  that  all  aequired  or  newly  developed  SCORM  packages  and, 
by  implication,  SCORM  objects  (SCOs)  include  metadata,  be  stored  in  a  repository,  and 
be  registered  in  the  ADL  Registry.  However,  this  requirement  does  not  imply  that  only 
SCORM  packages  can  be  registered. 

DoDl  1322.26  requirements  aside,  developers  are  encouraged  to  register  digital  objects 
that  others  could  share,  reuse,  or  repurpose.  The  scope  of  what  is  registered  may  vary.  It 
may,  for  example,  be  a  course,  a  module,  a  unit,  a  lesson,  a  topic,  or  a  single  asset,  such 
as  a  graphics  file.  Developers  may  register  a  single  object  in  a  package,  or  a  package  may 
contain  several  objects  with  a  complex  sequencing  structure.  They  may  also  register  a 
simulation,  video,  animation,  or  image  that  could  be  used  by  others. 

Some  topics,  such  as  the  following,  seem  more  likely  to  be  shared,  reused,  or  repurposed: 

1 .  Objects  that  are  of  interest  to  various  military  Services  or  other  organizations 
within  DoD,  such  as  those  that  concern 

•  Combating  trafficking  in  persons 

•  Combat  care  for  blast  injuries 

•  Tactical:  patrolling,  defensive  operations. 

2.  Objects  that  are  not  DoD  or  government  specific,  such  as  those  that  concern 

•  Accounting 

•  Leadership 

•  Medical/dental/pharmaceutical 

•  Regulatory  compliance,  such  as  job  safety  and  sexual  harassment. 

3.  Objects  that  are  governed  by  federal  rather  than  just  DoD  policy,  such  as  those 
that  concern 

•  Transportation  of  hazardous  materials  (HAZMAT) 

•  Federal  Acquisition  Regulations  (FARs) 

•  Air  Traffic  Control  (ATC). 

4.  Other  objects  that  could  be  useful  to  others,  such  as  those  that  concern 

•  Non-weapon-system-specific  topics 

•  Principles  of  navigation  (flight  or  naval  training) 

•  Vehicle  maintenance. 
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5.  Any  guidance  that  might  be  useful  to  others  and  that  could  be  packaged  in  an 
interehangeable  way  [e.g.,  a  Portable  Data  Format  (PDF)  file],  sueh  as 

•  Style  guides 

•  Glossaries 

•  Teehnieal  manuals. 

While  the  ADL  Registry  focuses  on  digital  objects,  it  also  permits  the  registration  of 
objects  that  are  not  available  for  downloading.  Such  objects  might  include  printed  books 
or  materials  available  on  compact  disks  (CDs).  Such  objects  may  be  registered  by 
submitting  the  same  deseriptive  metadata  that  would  be  submitted  for  downloadable 
objeets.  ADL  reeommends  that  the  loeation  of  such  an  object  resolve  to  a  Web  page  that 
gives  information  about  how  to  obtain  that  object. 

NOTE  -  The  ADL  Registry  eurrently  does  not  support  the  registration  of  classified  objects  even 
if  the  metadata  itself  is  unclassified. 

2.4  ADL  Registry  structure  and  functionality 

As  stated  previously,  the  ADL  Registry  is  a  centralized  service  that  manages  the 
proeessing,  storage,  identifieation,  and  indexing  of  information  about  digital  objeets  that 
are  stored  in  multiple,  independently  managed,  and  variously  located  repositories.  The 
ADL  Registry  does  not  store  objects.  It  only  stores  (and  indexes)  metadata  that  describes 
objects  located  and  managed  elsewhere.  This  distinction  is  important  and  sometimes 
eauses  confusion.  This  approach  provides  the  means  to  seareh  for  a  vast  number  of 
objeets,  with  minimal  impact  on  local  systems. 

Although  a  detailed  understanding  of  the  inner  workings  of  the  ADL  Registry  is  not 
required  to  seareh  for  or  register  digital  objects,  it  is  helpful  to  understand  the  ADL 
Registry’s  key  eomponents,  which  are  shown  in  Figure  6. 
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Figure  6  -  ADL  Registry  functional  modules  and  interfaces 

The  ADL  Registry  has  the  following  major  eomponents: 

Registry  engine;  Manages  information  that  is  sent  to  and  from  the  ADL  Registry  through 
the  ADL  Registry  Web  site  and  the  RIM-Lite  interfaee.  The  registry  engine  processes 
information  and  routes  it  internally  within  the  ADL  Registry.  It  is  responsible  for  all 
operations  inside  the  ADL  Registry,  including  authentication  and  authorization  of 
contributors. 
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Validator;  Ensures  that  Web  site  contribution-form  information  and  XML  files 
submitted  during  the  registration  transaction  process  are  valid  and  properly  formed.  It 
also  tests  incoming  information  against  a  set  of  rules  to  verify  that  incoming  information 
has  been  created  correctly. 

Metadata  record  repository;  Stores  metadata  records  submitted  by  object  repositories. 
The  records  include  unique  identifiers  for  internal  management  within  the  ADL  Registry 
that  are  created  using  the  handle  server. 

Index  engine;  Indexes  metadata  records  to  make  them  available  for  registry  searches. 

Handle  service;  Manages  the  creation  and  maintenance  of  unique  identifiers,  or  handles, 
and  provides  a  resolution  service  to  obtain  and  resolve  object  locations  from  the  handles. 
The  handle  service  can  administer  and  resolve  both  internal  registry  handles  and  external 
object  handles.  The  ADL  Registry  also  uses  handles  for  identifying  and  locating 
associated  local  registries  and  for  authenticating  and  authorizing  users.  (See  Section  2.6 
for  more  information  about  the  Handle  System.) 

Registry  Interface  Mechanism  (RIM-Lite);  The  external  access  point  to  the  ADL 
Registry  for  Web  sites  and  registry  tools  (see  Volume  3).  Web  site  developers  can  use 
RIM-Lite  to  provide  user  access  to  the  ADL  Registry  for  both  searching  for  and 
registering  digital  objects.  Tool  builders  can  use  RIM-Lite  to  build  custom  applications, 
such  as  tools  that  automatically  register  digital  objects  residing  in  repositories  and  custom 
search  tools. 

2.5  The  practice  registry 

Early  in  the  ADL  Registry  program,  it  became  clear  that  new  and  prospective 
contributors  needed  a  way  to  practice  registry  transactions  and  see  results  before 
undertaking  the  registration  of  a  large  number  of  digital  objects.  Also,  developers  needed 
a  way  to  test  automation  tools  and  interfaces  without  cluttering  the  operational  registry 
with  transient  test  information.  Therefore,  ADL  created  a  separate  practice  registry  that  is 
functionally  identical  to  the  operational  registry.  Requests  for  practice  registry  accounts 
can  be  made  through  the  ADL  Registry  Web  site,  which  also  provides  access  to  the 
practice  registry. 

The  practice  registry,  aside  from  its  access  procedures  and  policies,  is  identical  to  the 
operational  registry.  However,  because  it  is  a  test-bed  environment,  metadata  records 
need  not  point  to  actual  digital  objects  and  may  be  deleted  periodically  by  ADL.  Those 
who  use  the  practice  registry  should  maintain  local  copies  of  metadata  records  that  they 
may  later  contribute  to  the  operational  ADL  Registry.  Data  cannot  be  moved  from  the 
practice  registry  to  the  operational  registry. 

As  shown  in  Ligure  7,  the  practice  registry  uses  handle  prefixes  that  start  with  “4444”  to 
distinguish  between  contributions  made  to  the  practice  and  operational  registries.  All 
such  handles  apply  only  to  the  practice  registry.  All  handles  with  a  prefix  that  starts  with 
“100.50”  apply  only  to  the  operational  registry  (see  Section  2.6). 
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Figure  7  -  ADL  operational  and  practice  registries  and  their  prefix  identifiers 

NOTE  -  Because  the  practice  registry  is  also  ADL’s  test  bed  for  enhancements  and  debugging,  it 
may  be  temporarily  unavailable  during  ADL  test  cycles. 

2.6  The  Handle  System 

The  Handle  System  [8]  is  used  within  the  ADL  Registry  for  diseovery  (identifieation) 
and  resolution  (location)  of  digital  objects.  While  an  in-depth  understanding  of  the 
Handle  System  is  not  required  to  use  or  contribute  to  the  ADL  Registry,  some  may  desire 
a  basic  understanding  of  what  a  handle  is  and  how  it  is  used. 

The  Handle  System  is  a  comprehensive  system  for  assigning,  managing,  and  resolving 
identifiers  for  digital  objects  and  other  resources  on  the  Internet  and  other  computer 
networks.  It  functions  as  a  network-wide  directory  service,  ensuring  that  object-identifier 
information  remains  current. 

More  specifically,  the  Handle  System  includes  a  set  of  open  protocols,  a  namespace,  and 
an  implementation  of  the  protocols.  A  computer  system  can  store  handles  of  digital 
objects  in  a  distributed  environment  and  resolve  those  handles  into  the  information 
necessary  to  locate  and  access  the  objects.  This  information  is  changed,  as  needed,  by  the 
Handle  System  to  reflect  the  current  state  of  the  object  without  changing  the  handle  itself, 
which  persists  over  changes  of  location  and  other  information. 

As  shown  in  Figure  8,  a  handle  consists  of  two  parts:  a  prefix  and  a  suffix,  which  is  a 
unique  local  name.  The  names  are  separated  by  a  “/”.  A  handle  may  look  similar  to  a 
URL.  However,  when  an  object’s  location  changes,  its  URL  must  be  changed 
accordingly,  while  a  handle  is  persistent  regardless  of  object  location. 
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100.50.10/123456 


Figure  8  -  An  example  handle 

The  prefix  identifies  the  local  handle  service  that  is  responsible  for  the  handle.  ADL  can 
delegate  the  creation  of  prefixes  by  creating  sub-naming  authorities  for  DoD  publishers 
who  want  to  create  handles  for  their  own  objects.  Prefixes  and  suffixes  can  consist  of 
alpha  or  numeric  characters  or  a  combination  of  both.  Prefixes  used  by  ADL  Registry 
participants  are  numeric  and  begin  with  “100.50.” 

Each  DoD  component  or  approved  non-DoD  federal  activity  is  assigned  a  single  prefix 
consisting  of  100.50  and  two  additional  numbers,  for  example,  100.50.06.  Prefixes  for 
repositories  add  additional  numbers,  which  may  identify  additional  organizations  in 
addition  to  the  individual  repository.  For  example,  the  National  Defense  University’s 
prefix  is  100.50.06.02.  Each  of  the  university’s  five  colleges  is  identified  by  two 
additional  numbers,  for  example  100.50.06.02.01. 

3  Using  the  ADL  Registry  Web  site 

This  section  describes  the  step-by-step  procedures  that  repository  managers,  digital  object 
contributors,  and  registry  searchers  need  to  know  to  access  and  use  all  aspects  of  the 
ADE  Registry  Web  site;  http://adlregistrv.adlnet.gov. 

As  previously  mentioned,  ADE  provides  a  practice  registry.  Information  in  this  section, 
with  the  exception  of  some  registration  requirements,  applies  to  both  registries. 

3.1  Searching  the  ADL  Registry 

Anyone  can  search  the  ADL  Registry  for  metadata  about  registered  digital  objects.  No 
special  access  rights  are  required.  To  perform  a  basic  search,  simply  go  to  the  ADL 
Registry  home  page,  shown  in  Figure  9,  enter  your  search  terms,  and  click  »  search.  If 
you  need  to  document  a  search,  check  Request  Receipt  below  the  search  box  or  Request 
Receipt  for  this  Search  on  the  Search  Results  page  (see  Section  3.1.6). 

NOTE  -  This  section  assumes  that  you  want  to  search  the  operational  registry.  To  search  the 
practice  registry,  select  Practice  Registry  on  the  ADL  Registry  Web  site  home  page  and  then 
select  either  Basic  Search,  Advanced  Search,  or  Search  by  ID  from  the  drop-down  menu. 
Depending  upon  your  menu  choice,  a  search  page  equivalent  to  one  of  those  discussed  below  but 
applicable  to  the  practice  registry  will  be  displayed. 
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3.1.1  Basic  searches 

By  default,  the  ADL  Registry  performs  a  general  text  search  of  the  metadata  that 
describes  registered  digital  objects.  In  a  basic  search,  the  term  or  phrase  in  the  query  is 
used  to  search  the  title,  keyword,  and  description  fields  within  the  metadata.  Advanced 
searches  offer  additional  options  (see  Section  3.1.4  and  Appendix  B). 

A  basic  search  may  be  performed  from  the  ADL  Registry  home  page  shown  in  Figure  9 
or  from  the  page  shown  in  part  in  Figure  10,  which  is  accessed  by  selecting  Search  in  the 
main  menu  on  the  left  of  any  ADL  Registry  Web  page  and  then  selecting  Basic  Search 
from  the  drop-down  menu.  Enter  a  term  or  phrase  as  shown  and  click  »  search. 


Search 

Enter  your  search  criteria  then  click  search 


r  Request  Receipt 


Figure  10  -  A  basic  text  search 
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When  two  or  more  terms  are  entered  in  the  search  field,  the  ADL  Registry,  by  default, 
applies  the  Boolean  operator  “and”  to  the  terms.  In  the  example  shown  above,  the  ADL 
Registry  will  return  only  the  metadata  entries  that  contain  all  of  the  following  terms; 
medical,  blast,  and  injuries.  Capitalization  is  not  important.  The  ADL  Registry  returns  all 
word  matches  regardless  of  upper  or  lower  case. 

3.1.2  Search  results 

Metadata  is  registered  in  the  ADL  Registry  by  approved  contributors  who  know  best  how 
to  describe  their  own  digital  objects.  The  ADL  Registry  provides  a  standard  set  of 
metadata  that  all  contributors  must  use.  Contributors  may  include  additional  optional 
metadata  (see  Appendix  B  of  Volume  3).  Unlike  traditional  Internet  search  engines  that 
index  and  search  the  objects  themselves,  the  ADL  Registry  searches  only  the  metadata 
contained  in  the  registry  for  an  object.  This  search  method  improves  accuracy  and  limits 
search  results. 

Search  results  are  returned  as  a  paginated  list  of  entries.  As  shown  in  Figure  11,  each 
entry  contains  the  object’s  title  and  description  and  two  options:  a  button  to  access  the 
object  {get  object)  and  a  button  to  view  the  metadata  that  describes  the  object  {view 
metadata). 


Search  Results  ^  ^  ' 

Results  for  "blast  AND  injuries"  1 

Request  Receipt  for  this  Search 


Medical  Aspects  of  Blast  Injuries 

This  course  is  part  of  the  University  of  Pittsburgh  Supercourse.  The  course  was  aeated  by  Matthew  D. 
Sztajnkrycer.  MD.  PhD.  Assistant  Professor  of  Emergency  Medicine  at  the  Mayo  Clinic  and  Amado  Alejandro  Baez 
MD  Mscofthe  Mayo  Clinic.  The  course  addresses  both  the  pre-hospital  and  hospital  treatment  of  blast  injuries  as 
well  as  special  scenarios  for  blast  response.  The  course  is  registered  here  with  permission  from  the 
Supercourse. 

view  metadata  J 

1 


Figure  11  -  Search  results 


3. 1.2.1  Get  object 

The  results  of  clicking  get  object  will  vary  with  the  policies  of  the  participating 
repositories.  In  the  Figure  1 1  example,  clicking  get  object  displays  a  single  URL  of  type 
object,  as  shown  in  Figure  12. 
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Medical  Aspects  of  Blast  Injuries 

This  course  is  part  of  the  University  of  Pittsburgh  Supercourse.  The  course  was  created  by  Matthew  D. 
Sztajnkrycer,  MD.  PhD.  Assistant  Professor  of  Emergency  Medicine  at  the  Mayo  Clinic  and  Amado  Alejandro  Baez 
MD  Mscofthe  Mayo  Clinic.  The  course  addresses  both  the  pre-hospitai  and  hospitai  treatment  of  blast  injuries  as 
weli  as  special  scenarios  for  blast  response.  The  course  is  registered  here  with  permission  from  the 
Supercourse. 

Lx^L  view  metadata  J 

Object  httD.//www.iointadicolab.ora.'reDositorv^'blast  injures  orioinai/ 

1 


Figure  12  -  Get  object  results 

Depending  on  the  information  supplied  by  a  participating  repository,  clicking  get  object 
for  an  entry  may  display  one  or  more  of  the  following  clickable  URL  types: 

•  Object:  This  URL  should  point  directly  to  the  object  for  direct  download. 

•  Advertisement:  This  URL  may  provide  information,  such  as  thumbnails,  a  short 
video  clip,  a  sample  SCO  from  a  course,  screen  shots,  or  a  bulleted  list  of 
features,  to  help  you  decide  whether  you  want  to  acquire  the  object.  It  may  also 
provide  pricing  and  acquisition  information  when  an  object  must  be  purchased. 

•  Runtime:  This  URL  should  allow  you  to  launch  an  object,  such  as  a  course,  or 
view  an  object,  such  as  an  SI  GOOD  document  [6],  before  deciding  whether  to 
acquire  the  object.  You  may  be  required  to  present  log-in  credentials  before 
viewing  the  object. 

•  Contact:  This  URL  should  provide  information  for  a  point  of  contact  who  can 
provide  more  information  about  acquiring  the  object. 

•  Extended  Metadata:  This  URL  should  point  to  a  metadata  instance  that 
supplements  the  metadata  in  the  ADL  Registry  for  an  object.  For  example,  it 
could  point  to  a  metadata  instance  that  uses  the  MedBiquitous  Healthcare  schema. 

•  Repository:  This  URL  should  resolve  to  the  home  page  or  the  log-in  page  for  the 
repository  that  houses  the  object. 

3. 1.2.2  View  metadata 

As  shown  in  the  example  in  Figure  13,  clicking  view  metadata  opens  a  window  that 
displays  the  mandatory  metadata  submitted  to  the  ADL  Registry  by  the  contributor.  You 
can  use  this  metadata  to  help  determine  the  suitability  of  the  object  for  use  or  reuse. 
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View  Metadata  [jftkdQwnipadXMLjeJ 


Object  Information 


Title 

Medical  Aspects  of  Blast  Injuries 

Descnption. 

This  course  is  part  of  the  University  of  Pittsburgh 

Supercourse.  The  course  was  created  by  Matthew  D. 

Sztajnkrycer,  MD,  PhD,  Assistant  Professor  of  Emergency 

Medicine  at  the  Mayo  Clinic  and  Amado  Alejandro  Baez  MD 

Msc  of  the  Mayo  Clinic.  The  course  addresses  both  the  pre¬ 
hospital  and  hospital  treatment  of  blast  injuries  as  well  as 
special  scenarios  for  blast  response.  The  course  is 
registered  here  with  permission  from  the  Supercourse. 

Keywords 

blast  injuries 

lED  injury  treatment 

treating  blast  injuries 

pre-hospital  treatment  of  blast  injuries 

dirty  bomb  injuries 

hospital  treatment  of  blast  injuries 

Version  Number 

1.0 

Status: 

development  or  acquisition  completed 

Collection. 

DOD 

Contributor  Information 


Role 

author 

Name 

Date 

Nina  Pasini  Deibler 

2007-06-12 

Restriction  Information 


Copyright  Restriction  no 

Security  Level  unclassified 

Distribution  Restriction  lR 


Technical  Information 


Object  Type 

aggregation 

Object  Contents 
(MIME/Types) 
Metadata  Schema 

text/html 

image/jpeg 

LOMvI.O 

ADL-Rvl.O 

Compliance: 

SCORM  2004  3rd  Edition 

Identifiers 


Registry  ID 

100.3/registry 

Repository  ID 

Object  ID 

Metadata  Instance  ID: 

100.51/iadla 

100. 50.10. 13/suDercoursesamDle22 

100.3/MDsupercoursesample22124396 5442393 

Figure  13  -  View  metadata  results 
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From  the  view  metadata  window,  you  ean  eliek  download  XML  file  to  open  or  save  the 
XML  version  of  the  metadata.  You  might  want  the  XML  version  to  create  a  new 
metadata  record  for  a  particular  digital  object  or  to  see  the  structure  of  the  XML  used  in 
the  ADL  Registry.  The  XML  version  also  includes  any  optional  metadata  supplied  by  the 
contributor.  You  might  want  to  review  this  metadata  to  see  if  it  provides  additional 
information  to  help  determine  the  suitability  of  an  object  for  your  requirement. 

3.1.3  Specific-field  searches 

To  search  a  specific  metadata  field,  such  as  title  or  keyword,  enter  a  field  name  followed 
by  a  colon,  an  optional  space,  and  a  search  term  as  shown  in  Figure  14.  The  search  will 
be  limited  to  the  specified  field.  Alternatively,  you  can  use  the  advanced  search  form 
discussed  in  the  following  section  and  select  a  field  from  a  drop-down  menu.  (See 
Appendix  B  for  detailed  information  on  specific  field  searches.) 


Search 

Enter  your  search  criteria  then  click  search 


r  Request  Receipt 


Figure  14  -  A  specific-field  search 

3.1.4  Advanced  searches 

To  perform  an  advanced  search,  select  Search  from  the  main  menu  on  the  left  of  any 
page  and  then  select  Advanced  Search  from  the  drop-down  menu.  The  example  shown  in 
Figure  15  searches  for  all  digital  objects  related  to  navigation  except  stellar  navigation. 
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Advanced  Search 


Enter  your  search  criteria  into  the  fields  below  As  you  type,  the  query  will  be  built  and  placed  into  the 
search  field  When  you  are  ready,  click  search.  Click  here  for  more  information 


+navigation  -stellar  -stars  -celestial 


»  search 


r  Request  Receipt 


Figure  15  -  The  advanced  search  form 

By  default,  all  mandatory  elements  are  searehed.  If,  instead,  you  wanted  to  seareh  only 
object  titles,  you  would  click  the  down  arrow  and  select  title  from  the  drop-down  menu. 
The  search  box  is  filled  in  automatically  so  that  you  can  see  exactly  what  your  search 
looks  like.  (See  Appendix  B  for  detailed  information  on  advanced  searches.) 

3.1.5  Searching  by  identifier 

To  search  using  a  specific  repository,  object,  or  metadata  instance  identifier,  select 
Search  in  the  main  menu  on  the  left  of  any  page  and  then  select  Search  by  ID  from  the 
drop-down  menu.  As  shown  in  Figure  16,  you  could  search  for  all  objects  contributed  by 
the  Defense  Ammunition  Center  (DAC)  using  its  repository  ID. 
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Search  by  ID 


Enter  your  search  criteria  then  click  search. 


REPOSITORY  ID 


100.51/daca 


L  »  search 


OBJECT  ID 

[»  search ) 


METADATA  INSTANCE  ID 

[  »  search  ] 


Figure  16  -  Search  by  ID 

Similarly,  if  you  know  the  object  ID  or  metadata  instance  ID  for  a  particular  metadata 
entry,  you  can  enter  that  identifier  in  the  appropriate  field  to  find  a  specific  metadata 
record.  Repository,  object,  and  metadata  instance  IDs  are  displayed  on  the  View 
Metadata  page  (see  Section  3. 1.2.2). 

NOTE  -  The  repository  ID  is  assigned  by  the  ADL  Registrar  and  provided  to  the  repository 
manager.  A  direetory  of  repository  IDs  is  not  available  on  the  ADL  Registry  Web  site.  However, 
repository  IDs  for  a  speeifie  object  can  be  determined  by  viewing  the  metadata  for  the  object. 

3.1.6  Search  receipts 

The  ADL  Registry  offers  the  ability  to  document  your  search.  It  also  remembers  the  first 
page  of  a  documented  search.  If  you  need  to  document  a  search,  check  Request  Receipt 
from  the  search  page  before  executing  your  search  or  click  Request  Receipt  for  this 
Search  from  the  Search  Results  page.  As  shown  in  Figure  17,  the  search  results  will 
include  a  search-receipt  number  and  a  field  for  your  e-mail  address. 
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Search  Results 


Results  for:  "hazmat" 

Search  Receipt;  100  3/89e71feb78e5ed9377a0d48dc65a910e 
E-mail  Receipt: 


|Send| 


Showing  1-21  of  21 

1 


CBR  and  HAZMAT  Identification,  Protective  Equipment,  and  Measures 

CBR  and  HAZMAT  threats.  Capabilities  of  personnel  protective  equipment  and  clothing  along  with  protective 
measures  to  combat  against  threats  to  vital  Naval  resources. 

f  get  obiect  j  [  ^  View  metadata  j 


Figure  17  -  Results  including  a  receipt 

To  have  the  displayed  search  receipt  e-mailed,  enter  your  e-mail  address  and  click  Send. 
You  will  receive  an  e-mail  containing  information  similar  to  the  following: 

Search  Receipt:  100.3/bble224716539dc5ecfdb7bae41e3bdd 

http://adlregistry.adlnet.gov/search/resolveSearchID.jsp?id=100.3/bble224716539dc5 
ecfdb7bae4 1  e3bdd 

To  display  the  first  page  of  the  search  results,  you  can  click  the  URL  in  the  e-mail  or 
copy  it  into  your  browser.  Alternatively,  from  the  ADL  Registry  home  page,  you  can 
select  Search  from  the  main  menu  on  the  left  of  any  page  and  then  select  Resolve  Search 
Receipt  from  the  drop-down  menu  to  display  the  form  shown  in  Figure  18.  Copy  the 
search-receipt  number  into  the  field  and  click  Resolve. 


Search  Receipt 


Resolve  a  Search  Receipt  to  see  the  stored  results  of  a  query 


Search  Receipt:  100.3/bble224716539dc5ecfdb7bae41e3bdd 


Resolve 


Figure  18  -  The  search  receipt  form 

3.2  Registering  a  repository 

Before  a  digital  object  can  be  registered,  the  repository  in  which  it  is  stored  must  be 
registered.  Select  Contribute  in  the  main  menu  on  the  left  of  any  page  and  then  select 
Register  Repository  from  the  drop-down  menu.  The  repository  registration  form 
discussed  in  the  following  sections  will  appear.  After  filling  out  the  form  as  described  in 
the  following  sections,  click  »  submit  repository  registration  at  the  bottom  of  the  form  to 
send  the  information  to  the  ADL  Registrar. 
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NOTE  -  This  section  assumes  that  you  are  registering  a  DoD  repository.  After  registration,  you 
will  have  access  to  both  the  operational  and  practice  registries.  For  a  non-DoD  repository,  select 
Practice  Registry  from  the  main  menu  and  then  select  Register  Repository  from  the  drop-down 
menu.  The  procedure  is  the  same  except  that  your  repository  and  its  contributors  will  be 
associated  with  the  practice  registry  only,  and  you  do  not  need  to  provide  a  DoD  Component 
Proponent  or  sponsor  organization. 

3.2.1  The  repository  registration  form 

The  repository  registration  form  has  several  seetions  that  capture  information  about  a 
repository.  It  should  be  filled  out  by  or  under  the  direction  of  the  repository  manager.  The 
following  sections  summarize  the  required  information.  Once  the  form  has  been 
completed,  click  »  submit  repository  registration  to  send  the  form  to  ADL  for  processing. 

3.2. 1.1  Repository  information 

The  repository  information  section  of  the  form  is  shown  in  Figure  19.  The  repository  title 
is  your  organization’s  name  for  the  repository.  The  brief  description  should  include  what 
the  repository  is  used  for  and  by  whom  and  any  additional  information  that  would  be 
useful  for  the  ADL  Registrar  to  know  about  the  repository’s  functions  and  capabilities. 
The  location  is  the  URL  for  the  repository. 


Repository  Registration 

This  Repository  Registration  form  applies  to  DoD  Component  repositories  with  identified  Component 
Proponents  and  Sponsor  Organizations. 


Repository  Information 


General  Information  about  the  repository. 

Repository  Title  (common  name): 

ADL  Co-Lab  Repository _ 

Brief  Description: 

Stores  digital  objects  used  by  the  ADL  Co-Lab  and  other  ADL  facilities 
primarily  for  use  in  training,  education,  and  decision  aiding. 

Location  (URL): 

http://www.adlcolab.gov/repository/ 


Figure  19  -  Repository  information 
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3.2.1 .2  Repository  sponsor  information 

The  repository  sponsor  seetion  of  the  form  is  shown  in  Figure  20.  The  repository  sponsor 
is  the  DoD  organization  or  office  that  authorized  and  either  funded  or  approved  funding 
for  the  repository.  The  sponsor  organization  and  a  point  of  contact  must  be  supplied. 


Repository  Sponsor  Information 


The  Repository  Sponsor  is  the  organization  whose  mission  it  is  to  establish,  operate,  and  maintain  a 
repository.  The  Sponsor  Representative  must  be  a  government  employee 

Sponsor  Organization: 

ADL 

Organization  URL: 
http://www.adl.gov 
Representative  Name: 

Joe  Director 
E-mail  Address: 
director@adl.gov 
Telephone  Number: 

555-321-1212 

Address: 

123  ADL  Road 
City: 

ADLville 

State  (2  letter  abbreviation): 

VA 

Zip: _ 

12345 

Country: 

United  States 


Figure  20  -  Repository  sponsor  information 

3.2. 1.3  Repository  manager  information 

The  repository  manager  section  of  the  form  is  shown  in  Figure  21.  Enter  the  name  and 
contact  information  for  the  individual  who  is  directly  responsible  for  the  day-to-day 
management  of  the  repository  and  who  will  be  ADL’s  primary  point  of  contact.  This 
person  will  be  responsible  for  authorizing  repository  personnel  who  may  contribute  to 
ADL  Registry. 
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Repository  Manager  Information 


The  Repository  Manager  is  the  point  of  contact  for  a  repository.  The  manager  must  approve  all 
contributor  requests  and  changes  to  the  repository  registration.  This  manager  is  responsible  tor 
maintaining  the  accuracy  of  contributor  accounts  and  rrretadata  instances.  The  manager  may  be  a 
contractor  appointed  by  the  Repository  Sponsor  If  the  manager  is  a  contractor,  information  about  the 
contractor  organization  should  be  entered  below 

Are  you  the  Repository  Manager?  Yes  No  © 

OYou  will  be  asked  to  register  as  an  ADL  Registry  contributor  upon  completion  of  this  repository 
registration  form.  If  you  are  not  already  registered  as  a  contributor  you  are  required  to  complete 
I  contributor  registration  before  your  repository  registration  is  completed. 


Manager  Name: 

John  Manager 
Organization: _ 

ADL  Co-Lab  Hub 
Organization  URL: 
http://www.adlhub.gov 
E-mail  Address: 
manager@hub.gov 
Organization  URL: 

http  ://www.  a  d  I  hu  b .  g  o  V 
E-mail  Address: _ 

manager@hub.gov 
Telephone  Number: 

555-678-9101 
Address: _ 

manager@hub.gov 
Telephone  Number: 
555-678-9101 
Address: _ 

456  Hub  Street 
City: _ 

Hubtown 

State  (2  letter  abbreviation): 
VA 

Zip; _ 

56789 

Country: _ 

United  States 


Figure  21  -  Repository  manager  information 
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3.2. 1.4  Component  Proponent  information 

The  component  proponent  section  of  the  form  is  shown  in  Figure  21.  The  DoD 
Component  Proponent  is  the  person  or  office  who  authorized  the  existence  of  the 
repository  in  your  DoD  component.  You  may  select  one  of  the  military  Services  from  the 
drop-down  menu  or  select  Not  Listed  and  enter  the  Component  Proponent  information.  If 
the  identity  of  the  Component  Proponent  is  unknown  or  unclear,  leave  this  section  blank. 
The  ADL  Registrar  will  assist  in  making  a  determination. 


Component  Proponent  Information 


A  Component  Proponent  is  the  office  within  your  organizational  chain  of  command  that  has  been 
designated,  according  to  DOD1 1322.26  (paragraph  5.4.4  ).  as  the  approvai  authority  for  a  new  digital 
object  repository  Important;  If  your  DoD  Component  does  not  currently  have  a  proponent  identified  or 
your  repository  is  not  for  a  government  organization,  leave  this  section  blank  The  ADL  Registry 
Registrar  will  temporarily  function  as  your  proponent 


Proponent  Office: _ 

Not  Listed  V 


Proponent  Office: 

Representative  Name: 

(Include  Rank  or  Title) 

Phone: 

(commercial  or  DSN) 

E-mail: 


OSD 


John  Smith 


555-789-1011 


smith  (g>osdpr.gov 


Figure  22  -  Component  Proponent  information 

3.2. 1.5  Additional  information 

The  additional  information  section  of  the  form  is  shown  in  Figure  23.  All  information  in 
this  section  of  the  form  is  optional. 
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Additional  Information  (Optional) 


This  section  allows  you  to  provide  additional  information  that  may  be  relevant  to  your  repository 

Associated  Naming  Authorities: 

If  your  organization  already  has  an  assigned  Handle  System,  please  provide  that  prefix  here. 


Access  Information: 

Please  provide  a  description  of  any  repository  access  constraints  here. 

Access  Information: 


Security  Information: 

Please  provide  a  description  of  any  repository  security  constraints  here. 


Comments: 

If  you  have  any  comments  that  you  would  like  the  ADL  Administration  staff  to  know  about  your 
repository,  registration  experience,  or  any  other  aspect  of  the  ADL  Registry  project;  please 
provide  those  comments  here 


Figure  23  -  Additional  information 

Associated  Prefixes:  If  your  repository  already  has  one  or  more  assigned  Handle  System 
prefixes,  enter  them  here.  If  not,  ADL  will  assign  prefixes  -  one  to  use  with  the 
operational  registry  and  the  other  with  the  praetiees  registry.  (Most  repositories  will  not 
already  have  assigned  prefixes.  See  Seetion  2.6.) 
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Access  Information;  This  information  should  describe  what  access  by  whom  is  granted 
to  the  repository.  For  example,  it  should  describe  the  type  of  user  authentication  required 
and  how  digital  objects  or  other  information  may  be  accessed.  If  special  access 
limitations  exist,  they  should  be  noted  here. 

Security  Information;  Any  specific  security  limitations  to  the  use  or  access  of  the 
repository  or  its  digital  objects  should  be  noted  here.  (As  previously  stated,  the  ADL 
Registry  does  not  support  the  registration  of  classified  objects.) 

Comments;  Any  special  notes  or  aspects  about  the  repository  that  would  be  of  interest  to 
ADL  Registrar  should  be  noted  here. 

3.2.2  Repository  registration  confirmation 

After  the  registration  form  has  been  submitted,  you  will  receive  the  confirmation  shown 
in  Figure  24. 


Repository  Registration  Submitted 

Your  request  has  successfully  been  submitted. 

You  will  receive  an  e-mail  from  the  ADL  Registry  Registrar  (acllregistry@adlnet.gov)  once  your 
repository  application  has  been  processed.  Following  that,  you  will  receive  an  e-mail  from  the  ADL 
Registry  Support  Team  (adirhelpdeskfaiadinet  oovt  containing  your  repository's  registration  information 
-  namespace(s),  identifier,  and  group  identifiers.  Your  ADL  Practice  Registry  account  will  be  activated. 
Your  ADL  Registry  account  will  not  be  activated  until  you  have  actively  participated  in  the  ADL  Practice 
Registry.  When  you  are  ready  to  activate  your  ADL  Registry  account,  please  contact  the  ADL  Registry 
Support  Team  via  e-mail  at  adlrhelDdesk@adlnet  oov. 

Next  Step: 

Click  to  register  as  a  contributor  for  this  repository  In  order  to  complete  your  repository 
registration  the  repository  manager  must  complete  the  Contributor  Registration  process.  If  you  are 
already  registered,  you  may  navigate  elsewhere  on  the  web  site 


Figure  24  -  Repository  registration  confirmation 

The  ADL  Registrar  will  review  the  application  and  contact  the  repository’s  DoD 
Component  Proponent  for  approval.  The  registrar  will  notify  the  repository  sponsor  and 
the  ADL  Registry  Help  Desk  when  the  repository  is  approved.  If  more  information  or 
clarification  is  needed  before  approval,  the  registrar  will  contact  the  repository  manager. 

The  help  desk  will  then  contact  the  repository  manager  to  establish  accounts  for 
contributors  who  are  to  be  authorized  to  contribute  metadata  records  to  the  ADL 
Registry.  The  repository  manager  is  responsible  for  keeping  these  accounts  current  and 
will  be  contacted  by  the  help  desk  when  a  contributor  account  request  is  received. 

(To  register  a  contributor,  see  Section  3.3.) 
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3.2.3  Final  steps 

Once  the  registration  form  has  been  validated  and  the  ADL  Registrar  has  approved  the 
repository,  it  will  be  assigned  a  unique  handle  prefix.  This  prefix  is  used  to  form  the 
persistent  identifier  for  all  digital  objeets  that  are  registered  in  the  ADL  Registry.  (See 
Section  2.6  for  more  information  on  handles  and  prefixes.) 

Repositories  owned  or  managed  by  DoD  organizations  or  other  approved  federal 
activities  will  be  assigned  a  handle  prefix  (e.g.,  100.50.1.2)  for  the  operational  ADL 
Registry.  All  these  prefixes  start  with  100.50  and  are  used  to  build  the  handles  that 
identify  objects  within  a  repository.  Repositories  will  also  be  assigned  a  unique 
repository  identifier  (e.g.,  100.5 1/adlrepository).  This  identifier  is  used  to  speeify  the 
repository  in  metadata  records  (see  Seetion  5.3). 

NOTE  -  Repositories  with  an  operational  registry  account  are  also  given  a  practice  registry 
account  with  a  handle  prefix  of  “4444”. 

3.3  Registering  a  contributor 

At  the  request  of  a  repository  manager,  ADL  will  provide  access  rights  to  individuals 
who  may  contribute  metadata  to  the  ADL  Registry  on  behalf  of  a  repository.  Contributors 
must  be  registered  to  submit  metadata. 

Aecess  to  the  ADL  Registry  is  granted  by  creating  contributor  groups.  To  obtain  access 
rights,  a  contributor  must  be  a  group  member.  Rights  are  not  granted  direetly  to 
individual  contributor  accounts. 

NOTE  -  This  section  assumes  that  you  are  registering  a  contributor  for  the  operational  registry. 
After  registration,  the  contributor  will  have  access  to  both  the  operational  and  practice  registries. 
To  register  a  contributor  for  the  practice  registry  only,  select  Practice  Registry  from  the  main 
menu  and  then  select  Register  Contributor  from  the  drop-down  menu.  The  procedure  is  the  same 
except  that  the  contributor  will  have  access  to  the  practice  registry  only. 

3.3.1  The  contributor  registration  form 

To  register  a  eontributor,  seleet  Contribute  from  the  main  menu  on  the  left  of  any  page 
and  then  seleet  Register  Contributor  from  the  drop-down  menu.  The  eontributor 
registration  form,  shown  in  Figure  25,  eaptures  the  eontributor’ s  contaet  information  as 
well  as  information  about  the  repository  and  its  manager.  The  form  should  be  eompleted 
by  or  under  the  direction  of  the  repository  manager. 
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Contributor  Registration 

This  Contributor  Registration  form  applies  to  contributors  who  have  registered  repositories  with  the 
ADL  Registry  Click  here  for  more  information 


Contributor  Information 


Name: 

|joe  Contribute 

E-mail  Address: 
contributor@hub.gov 
Telephone  Number: 

555-234-5678 


Repository  Information 


Repository  Name/ID: 

Please  provide  either  your  repository  idehtifier  which  your  Repository  Manager  should  be  able  to 
provide,  or  the  full  name  and  service  of  your  repository  (e  g  .  Navy  CMAD ILE  Repository) 

ADL  Co-Lab  Repository _ 

Repository  Manager  Name: 

John  Manager _ 

Repository  Manager  E-mail  Address: _ 

|manager@hub.gov 


Contributor  Organization  Information 


Organization  Name: 

|ADL  Co-Lab  Hub  | 

Organization  URL: 

htlp://vww  adlhub.gov 

Address: 

456  Hub  Street _ 

City: 

[HubTown  | 

State: 

VA 

Zip: _ 

56789 _ 

Country: 

I  United  States  v  | 

»  submit  contributor  registration^] 


Figure  25  -  The  contributor  registration  form 

Once  the  form  has  been  completed,  eliek  »  submit  contributor  registration.  The  message 
in  Figure  26  will  be  displayed,  and  the  form  will  be  sent  to  ADL  for  processing.  The 
ADL  Registry  Help  Desk  will  eontact  the  repository  manager  and  request  authorization  to 
provide  the  contributor  appropriate  aeeess  rights  to  the  ADL  Registry. 

NOTE  -  For  non-DoD  and  non-approved  federal  organizations,  eontributors  will  automatically  be 
associated  with  the  practice  registry. 
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Contributor  Registration  Submitted 

Your  request  has  been  successfully  submitted. 

You  will  receive  an  e-mail  from  the  ADL  Registry  Helpdesk  (adlrhelpdesktSiadlnet  oovt  containing  your 
Username  and  a  temporary  Password  for  your  ADL  Registry  contributor  account.  Once  you  have 
received  your  login  information,  please  visit  the  website  to  change  vour  password. 

Your  ADL  Practice  Registry  account  will  be  activated  Your  ADL  Registry  account  will  not  be  activated 
until  you  have  actively  participated  in  the  ADL  Practice  Registry.  When  you  are  ready  to  activate  your 
ADL  Registry  account,  please  contact  the  ADL  Registry  Support  Team  via  e-mail  at 
adlrhelpdesk(a)adlnet  gov 


Figure  26  -  Contributor  registration  confirmation 

3.3.2  Contributor  rights 

The  types  of  transactions  a  contributor  can  perform  when  submitting  or  manipulating 
metadata  records  depend  on  the  rights  given  to  the  contributor.  The  ADL  Registry  Help 
Desk  provides  these  rights  by  assigning  contributors  to  contributor  groups.  (See  Section  5 
for  information  about  transaction  types.) 

The  help  desk  creates  two  groups  for  a  repository.  The  first  group  is  intended  for  typical 
contributors.  The  second  group  is  intended  for  managers  and  advanced  contributors.  The 
transaction  permissions  associated  with  each  of  these  groups  are  as  follows: 

•  Contributor  group:  insert,  update,  activate,  search,  and  deactivate. 

•  Manager  group:  insert,  update,  activate,  search,  deactivate,  delete,  withdraw,  and 
move. 

The  repository  manager  is  responsible  for  determining  the  groups  to  which  contributors 
are  assigned  and  for  notifying  contributors  of  their  group  membership  and  associated 
rights. 

3.4  Contributing  metadata 

Digital  objects  are  contributed  by  submitting  transactions  that  contain  metadata  to  the 
ADL  Registry.  The  metadata  is  stored  in  the  ADL  Registry.  The  objects  themselves 
reside  in  the  contributing  repositories.  Additional  transactions  allow  manipulation  of  the 
metadata.  Each  type  of  transaction  (insert,  update,  activate,  deactivate,  delete,  withdraw, 
and  move)  follows  the  same  submission  process.  (See  Section  5  for  more  information  on 
transaction  types.) 

The  ADL  Registry  Web  site  provides  two  ways  to  contribute  metadata.  You  can  either 
use  an  online  form  to  describe  your  object  or  upload  an  XML  transaction  file  that 
describes  the  object. 
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3.4.1  Contributing  metadata  with  the  oniine  form 

To  contribute  metadata  using  the  online  form,  select  Contribute  from  the  main  menu  on 
the  left  of  any  page  and  then  select  Contribute  with  Form  from  the  drop-down  menu  to 
display  the  log-in  form  shown  in  Figure  27. 

NOTES: 

1.  This  section  assumes  you  are  contributing  metadata  to  the  operational  registry.  To  contribute  to 
the  practice  registry,  select  Practice  Registry  from  the  main  menu  and  then  select  Contribute  with 
Form  from  the  drop-down  menu.  The  information  required  to  register  an  object  is  the  same. 

2.  To  simplify  the  use  of  the  online  form,  it  has  been  designed  to  accept  the  minimum  amount  of 
information  needed  to  register  an  object.  Additional  information  is  supported  when  metadata  is 
contributed  by  uploading  an  XML  file.  (See  Sections  3.4.2  and  4.) 


Contribute  Metadata  with  Form 


Use  this  tool  to  create  and  submit  an  ADL  Registry  transaction  fiie  for  contributing  or  changing  digitai 
object  metadata  by  fiiiing  out  an  interactive  form  After  the  file  has  been  created,  you  can  view, 
download,  and  submit  your  transaction  Ciick  here  for  more  information 


Contributor  Information 


All  fields  in  this  section  are  required 


User  Name: 

jsmithOOl 

Password: 


E-mail  Address: _ 

John  smith@navsea_repositofy  mil _ 

Group  ID:  Q 

4444  grp/navsearepositoryOOt 


[Continue] 


Figure  27  -  Logging  into  the  online  contribution  form 

Enter  the  user  name  and  group  ID  that  were  assigned  to  you  when  you  registered  as  a 
eontributor,  your  password,  and  your  e-mail  address  and  then  eliek  Continue.  The  menu 
shown  in  Figure  28  will  be  displayed. 
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Contribute  Metadata  with  Form 

Select  the  type  of  Registry  action  for  this  metadata  record 


Action 


O  Register  a  digital  object  for  the  first  time  (insert) 

O  Register  an  additional  metadata  record  for  a  digital  object  (insert) 
O  Delete  a  metadata  record  (delete) 

O  Update  a  metadata  record  (update) 

O  Activate  a  metadata  record  (activate) 

O  Deactivate  a  metadata  record  (deactivate) 

O  Unregister  a  digital  object  (withdraw) 

O  Change  digital  object's  location  (move) 


|Continue| 


Figure  28  -  Selecting  a  transaction  type 

Select  Register  a  digital  object  for  the  first  time  (insert)  and  then  click  Continue.  A 
multipart  contribution  form  will  be  displayed.  (See  Section  5.2  for  an  explanation  of  the 
other  transactions  in  the  menu.) 

The  rest  of  this  section  gives  an  example  of  using  the  form  to  register  a  hypothetical 
sonar  course.  Note  that  the  ADL  Registry  Web  site  fills  in  some  fields  of  the  form  with 
information  that  is  constant  for  contributing  a  new  object.  To  see  this  information,  click 
additional  information  in  the  various  sections  of  the  form. 

3.4.1. 1  General  information 

Provide  a  title,  keywords  (or  phrases)  that  will  be  useful  to  searchers  and  a  brief 
description  as  shown  in  Figure  29.  Keywords  should  be  chosen  carefully  to  ensure  their 
usefulness.  They  will  be  the  primary  means  used  by  searchers  to  find  your  object. 

To  add  keywords,  enter  a  keyword  into  the  input  field  and  then  c\ic\^  Add.  The  item  will 
be  transferred  to  the  larger  box.  To  remove  a  keyword,  click  on  it  in  the  larger  box  and 
then  click  Remove. 
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B  General  Digital  Object  Information 


This  section  includes  basic  descriptive  information  about  your  digital  object  All  fields  in  this  section  are 
required  You  must  provide  at  least  one  descriptive  keyiword  for  your  digital  object  by  entering  a 
keyword  into  the  field  and  clicking  Add 

Title;  O 


Figure  29  -  General  information 


NOTES: 

1.  The  title  field  is  limited  to  1,000  charaeters. 

2.  Be  sure  to  click  Add  after  entering  each  keyword.  Failure  to  do  so  will  result  in  either  the 
keyword  being  ignored  or  an  error,  depending  on  whether  the  large  box  contains  any  information 
when  the  contribution  form  is  submitted  for  processing. 

3.4.1. 2  Life-cycle  information 

As  shown  in  Figure  30,  enter  the  version  of  your  digital  objeet  according  to  whatever 
versioning  scheme  your  repository  uses  and  then  select  its  status  from  the  drop-down 
menu.  If  multiple  versions  of  an  object  are  to  be  registered,  register  each  as  a  separate 
object.  The  status  value  indicates  either  whether  the  object  is  a  draft,  final,  or  revision,  or 
the  current  phase  of  the  program  for  which  the  object  is  being  registered  according  to  the 
terminology  used  in  DoDI  1322.20  [1]. 

NOTE  -  The  version  field  is  limited  to  50  characters. 
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Digital  Object  Life  Cycle  Information 


This  section  includes  information  about  the  history  and  current  status  of  your  digital  object  All  fields  in 
this  section  are  required 

Version:  O 


10 

Status  Value: 

o 

development  or  acquisition  completed 

V 

Figure  30  -  Life-cycle  information 

3.4.1. 3  Contributor  information 

As  shown  in  Figure  31,  enter  the  name  of  the  digital  object’s  author. 


B  Digital  Object  Contributor  Information 


This  section  identifies  the  author  of  the  digital  object  Required  fields  are  marked  with  an  asterisk  (*). 


Prefix:  First  Name*:  Middle  Name: 


Dr 

John 

R 

Last  Name*:  Suffix: 

Smith 

additional  information 


Figure  31  -  Contributor  information 

NOTE  -  Each  of  the  contributor  information  fields  is  limited  to  148  characters. 

3.4.1. 4  Metadata  schema  information 

To  view  this  section  of  the  form,  click  +  to  the  immediate  left  of  the  section  title  shown 
in  Figure  32  to  display  the  information  shown  in  Figure  33.  This  section  of  the  form 
specifies  the  metadata  schemas  used  to  develop  the  metadata  for  your  digital  object.  The 
values  “LOMvl.O”  and  “ADL-Rvl.O”  are  required  and  cannot  be  changed.  Although  you 
cannot  specify  additional  schemas  with  the  contribution  form,  you  can  do  so  when 
registering  an  object  by  uploading  an  XIVIL  file  (see  Section  3.4.2). 


□  Metadata  Schema  Information 


Figure  32  -  Metadata  schema  information  (collapsed) 
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H  Metadata  Schema  Information 


This  section  includes  information  that  the  ADL  Registry  needs  to  correctly  interpret  the  metadata  format 
used  by  the  transaction  file.  The  information  in  this  section  is  required  and  cannot  be  changed 

Schema:  LOMvI.O 

Schema:  ADL-Rvi  0 


Figure  33  -  Metadata  schema  information  (expanded) 

3.4.1 .5  Technical  information 

As  shown  in  Figure  34,  specify  all  file  formats  used  by  your  digital  object.  Formats  are 
specified  as  Multipurpose  Internet  Mail  Extension  (MIME)  types  [5],  which  are  reflected 
in  file  name  extensions.  If  your  object  includes  files  that  do  not  have  MIME  types,  use 
“other”  for  these  files.  A  reference  for  MIME  types  is  available  at 

http://www.w3schools.com/media/media  mimeref  asp. 

The  additional  value  “non-digital”  is  allowed  for  objects  that  are  not  available  for 
downloading,  such  as  a  course  that  is  available  only  on  a  CD. 

To  add  a  format,  enter  it  into  the  input  field  and  then  click  The  item  will  be 
transferred  to  the  larger  box.  To  remove  a  format,  click  on  it  the  larger  box  and  then  click 
Remove. 


Q  Digital  Object  Technical  Information 


This  section  includes  information  about  the  types  of  files  contained  in  your  digital  object  Some  file 
types  may  require  special  software  In  order  to  display  properly  All  fields  in  this  section  are  required 
For  each  format  enter  it  into  the  field  and  click  Add 


Format: 

(Example;  text/html)  O 


Figure  34  -  Technical  information 

NOTE  -  Be  sure  to  click  Jc/c/  after  entering  each  format.  Failure  to  do  so  will  result  in  either  the 
format  being  ignored  or  an  error,  depending  on  whether  the  large  box  contains  any  information 
when  the  contribution  form  is  submitted. 
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3.4.1. 6  Copyright  information 

As  shown  in  Figure  35,  specify  whether  your  digital  object  is  copyrighted.  Choosing 
“yes”  does  not  preclude  others  from  sharing  your  object.  It  simply  informs  them  that 
restrictions  exist. 


H  Digital  Object  Copyright  Information 


This  section  specifies  whether  copyrights  or  other  intellectual  property  restrictions  apply  to  the  digital 
object 

Copyright  and  Other  Restrictions  Value:  O 

no  v 

additional  information 


Figure  35  -  Copyright  information 

3.4.1. 7  Security  classification  information 

To  view  this  section  of  the  form,  click  +  to  the  immediate  left  of  the  section  title  shown 
in  Figure  36  to  display  the  information  shown  in  Figure  37.  The  fields  in  this  section  of 
the  form  cannot  be  changed.  Currently,  the  ADL  Registry  supports  registering 
unclassified  digital  objects,  only. 


□  Digital  Object  Security  Classification  Information 


Figure  36  -  Security  classification  information  (collapsed) 


B  Digital  Object  Security  Classification  Information 


t  The  ADL  Registry  currently  supports  ONLY  unclassified  digital  objects. 

A  classified  object  cannot  be  registered  even  if  the  metadata  about  that  object  is 
unclassified. 


Purpose  Source: 
Purpose  Value: 
Taxonomy  Source 
Taxonomy  Entry: 


LOMv1  0 
security  level 

ADL/DOD  Security  Taxonomy 
unclassified 


Figure  37  -  Security  classification  information  (expanded) 
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3.4.1. 8  Type  information 

As  shown  in  Figure  38,  specify  whether  your  digital  object  is  an  individual  asset  (e.g.,  an 
image,  a  competency,  or  a  technical  document),  a  single  SCORM  SCO,  or  an  aggregation 
of  two  or  more  objects  (e.g.,  a  collection  of  assets  or  a  SCORM  package  containing  two 
or  more  SCOs).  Select  other  if  none  of  the  specific  menu  choices  are  appropriate. 


□  Digital  Object  Type  information 


This  section  specifies  the  type  of  digital  object 

Taxonomy  Entry:  O 

aggregation _ ^ 

additional  information 


Figure  38  -  Type  information 

NOTE  -  If  you  feel  that  a  new  objeet  type  should  be  added  to  the  menu  of  types,  please  contaet 
the  ADL  Registry  Help  Desk. 

3.4.1. 9  Distribution  restriction  information 

As  shown  in  Figure  39,  specify  any  restrictions  on  the  distribution  of  your  digital  object. 
For  objects  related  to  learning,  such  as  courses,  modules,  and  media  assets  that  might  be 
used  in  courses,  select  one  of  the  descriptive  statements  in  the  first  half  of  the  menu.  For 
documents,  such  as  SI  GOOD™  [6]  technical  manuals,  select  one  of  the  distribution  state¬ 
ments.  If  you  are  not  sure  which  menu  choice  applies  to  your  object,  ask  your  repository 
manager  or  security  officer.  Descriptive  choices  are  based  on  DoDI  1322.20  [1].  Distri¬ 
bution  statements  are  based  on  Department  of  Defense  Directive  (DoDD)  5230.24  [3]. 


B  Digital  Object  Distribution  Restriction  Information 


This  section  specifies  any  restrictions  to  the  distribution  of  your  digital  object  Government-owned  or 
controlled  objects  must  be  assigned  one  of  the  distribution  codes  or  statements  provided  in  the  list 
below  Consult  your  repository  manager  or  security  officer  if  there  is  any  question  as  to  which  option 
applies 

Taxonomy  Entry:  Q 

CD  -  Cleared  for  DoD  Distribution  Only _ ^ 

additional  information 


Figure  39  -  Distribution  restriction  information 
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3.4.1.10  Compliance  information 

This  section  of  the  form  describes  the  primary  specification  or  standard  that  applies  to 
your  digital  object.  As  shown  in  Figure  40,  select  a  specification  from  the  menu  or  select 
other  if  your  object  complies  with  a  specification  that  is  not  listed.  If  compliance  does  not 
apply  to  your  object,  select  none. 

NOTE  -  Although  the  registration  form  supports  the  specification  of  only  one  compliance  value, 
you  can  provide  multiple  values  when  registering  a  digital  object  by  uploading  and  XML  file  (see 
Section  3.4.2) 


B  Digital  Object  Compliance  information 


This  section  specifies  the  standard  or  specification  that  appiies  to  your  digital  object  The  ADL  Registry 
is  not  limited  to  SCORM  objects 

Taxonomy  Entry:  Q 

SCORM  2004  3rd  Edition  v 

additional  Information 


Figure  40  -  Compliance  information 

3.4.1.11  Collection  information 

As  shown  in  Figure  41,  specify  the  groups  that  may  find  your  digital  object  to  be  useful. 
At  minimum,  specify  “DOD”.  You  may  specify  additional  applicable  categories,  such  as 
DAC  or  NAVAIR,  by  entering  them  after  “DOD”  in  the  provided  input  field. 


B  Digital  Object  Collection  Information 


This  section  includes  information  about  your  digital  object's  grouping  or  category  of  usage  as  it  may 
apply  to  a  target  audience  ADL  recommends  the  value  "DOD"  in  this  field  You  may  enter  additional 
values  if  appropriate 

Taxonomy  Entry:  O 

DOD  NAVSEA 
additional  information 


Figure  41  -  Collection  information 

NOTE  -  The  collection  field  is  limited  to  500  characters. 
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3.4.1.12  Educational  objective  information 

This  section  of  the  form  is  optional.  To  view  this  section  of  the  form,  click  +  to  the 
immediate  left  of  the  section  title  shown  in  Figure  42.  As  shown  in  Figure  43,  you  may 
enter  the  educational  objective’s  source  (Taxonomy  Source),  its  unique  identifier  (Taxon 
ID),  and  its  descriptive  title  or  objective  summary  statement  (Taxonomy  Entry). 


□  Educational  Objective  Information 


Figure  42  -  Educational  objective  information  (collapsed) 


Figure  43  -  Educational  objective  information  (expanded) 

NOTE  -  Although  this  section  of  the  form  is  optional,  if  you  provide  educational  objective 
information,  you  must  provide  input  for  all  three  fields. 

3.4.1.13  Competency  information 

This  section  of  the  form  is  optional.  To  view  the  section,  click  +  to  the  immediate  left  of 
the  section  title  shown  in  Figure  44.  As  shown  in  Figure  45,  you  may  enter  the 
competency’s  source  (Taxonomy  Source),  its  unique  identifier  (Taxon  ID),  and  its 
descriptive  title  or  summary  statement  (Taxonomy  Entry). 


□  Competency  Information 


Figure  44  -  Competency  information  (collapsed) 
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H  Competency  Information 


This  section  includes  information  about  your  digital  object's  competency  data  This  section  is  optional, 
but  if  you  provide  input,  all  fields  are  required 


Taxonomy  Source:  Q 


additional  information 


Figure  45  -  Competency  information  (expanded) 

NOTE  -  Although  this  section  of  the  form  is  optional,  if  you  provide  competency  information, 
you  must  provide  input  for  all  three  fields. 

3.4.1.14  Transaction  information 

As  shown  in  Figure  46,  enter  a  unique  ID  for  your  digital  objeet  and  enter  your 
repository’s  ID. 


B  Transaction  Information 


All  fields  in  this  section  are  required 

Object  Identifier:  O 

10.5Q.1Q.1/sonarcourse1 _ 

Repository  Identifier:  Q 

1QQ.51/navsearepository 

additional  information 


Figure  46  -  Transaction  information 

NOTE  -  The  identifier  fields  are  limited  to  255  characters  each. 

3.4.1.15  Object  location  information 

As  shown  in  Figure  47,  enter  one  or  more  loeations  (URLs)  for  your  digital  object.  (See 
Section  3. 1.2.1  for  an  explanation  of  the  various  locations.) 
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B  Object  Location  Information 


This  section  allows  you  to  provide  one  or  more  locations  for  your  digital  object  Each  location  provides 
a  different  way  to  experience  the  object.  At  least  one  location  must  be  provided 

Object:  O 


IContinue  &  ContribuTe 


Figure  47  -  Object  location  information 

3.4.1.16  Submitting  your  contribution 

To  submit  your  contribution,  click  Continue  &  Contribute  at  the  bottom  of  the 
contribution  form  (see  Figure  47).  Assuming  you  have  filled  out  the  form  correctly,  a 
transaction  file  will  be  created  and  the  acknowledgement  shown  in  Figure  48  will  be 
displayed.  If  the  contribution  form  contains  an  error,  you  will  be  returned  to  the  form. 


Contribute  Metadata  with  Form 

Please  choose  an  action  below  to  continue  your  transaction  Please  note  that  it  you  would  like  to  save 
a  copy  of  your  transaction  file,  you  must  do  so  before  transmitting  it  to  the  ADL  Registry 

f  Your  AOL  Registry  Transaction  has  not  yet  been  completed. 

•  View  Transaction  File 

•  Download  Transaction  File 

•  Send  Transaction  File  to  ADL  Registry 

•  Discard  Session  and  Start  Over 


Figure  48  -  Final  steps 

You  can  view  or  download  the  XML  transaetion  file  for  your  submission  or  delete  your 
submission  and  start  over  by  clicking  the  appropriate  menu  choice.  To  submit  the 
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transaction  and  register  your  digital  object,  click  Send  Transaction  File  to  ADL  Registry. 
If  you  leave  this  page  without  sending  your  transaetion  file  to  the  ADL  Registry,  your 
object  contribution  will  be  discarded.  (To  determine  the  results  of  your  submission,  see 
Section  3.4.3.) 

3.4.2  Contributing  metadata  by  upioading  an  XML  fiie 

Instead  of  using  the  online  form,  you  ean  eontribute  metadata  by  uploading  an  XML 
transaetion  file  that  contains  the  metadata  that  describes  your  digital  object  and  the 
transaetion  to  be  performed.  Sections  4  and  5  provide  more  information  on  digital  objeet 
and  transaetion  metadata,  respeetively.  Volume  3  gives  detailed  information  on  these 
topies. 

To  eontribute  metadata  buy  uploading  an  XML  file,  seleet  Contribute  in  the  main  menu 
on  the  left  side  of  any  page  and  then  select  Contribute  with  XML  File  from  the  drop-down 
menu  to  display  the  form  shown  in  Figure  49. 


Contribute  Metadata  with  XML  Fiie 

Use  this  form  to  upload  a  transaction  file  to  the  ADL  Registry  Click  here  for  more  information 


[  »_ submit  metadata)) 


Figure  49  -  Contributing  metadata  with  an  XML  file 

Enter  the  user  name  that  was  assigned  to  you  when  you  registered  as  a  eontributor,  your 
password,  and  your  e-mail  address.  In  the  Upload  XML  File  field,  either  enter  the 
complete  path  ineluding  the  file  name  of  the  XML  file  you  want  to  submit  or  eliek 
Browse...  to  navigate  to  the  file.  Onee  the  form  has  been  eompleted,  eliek  »  submit 
metadata.  (To  determine  the  results  of  your  submission,  see  Seetion  3.4.3.) 

NOTE  -  Although  an  e-mail  address  is  not  required,  you  should  provide  one  if  your  XML  file  is 
greater  than  1 0  MB  in  size  beeause  the  ADL  Registry  may  not  process  your  submission 
immediately.  Doing  so  allows  the  ADL  Registry  to  notify  you  of  your  submission’s  status  by 
e-mail.  The  notification  e-mail  contains  an  XML  description  of  the  contribution  and  is  intended 
primarily  for  developers  who  submit  large  XML  files.  If  the  ADL  Registry  does  not  process  your 
transaction  immediately,  you  will  be  notified  by  e-mail  that  processing  is  pending  and  again  when 
the  transaction  has  been  processed.  (See  Section  3.4.3  for  more  information  on  events  after 
transaction  submission.) 
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3.4.3  Contribution  resuits 


If  you  submitted  your  metadata  by  uploading  an  XML  file  and  your  metadata  contained 
no  errors  that  prevented  its  processing,  you  will  receive  a  message  similar  to  the  one 
shown  in  Figure  50.  If,  instead,  you  receive  an  error  message,  note  the  error  code.  You 
can  either  contact  the  ADL  Registry  Help  Desk  via  the  provided  link  or  see  Section  6  to 
learn  more  about  common  errors. 

If  you  submitted  your  metadata  using  the  contribution  form,  a  message  similar  to  the  one 
in  Figure  50  will  always  be  displayed.  Using  the  form  ensures  that  the  metadata  is 
properly  formatted  for  processing. 


Contribution  Resuit 

Your  contribution  has  been  sent  to  the  ADL  Registry. 

If  you  provided  an  e-mail  address  you  will  be  notified  by  e-mail  once  your  contribution  request  has  been 
processed 


Validation  Identifier 


This  number  may  be  used  to  check  the  ADL  Registry's  progress  at  ensuring  your  submission  is 
properly  formatted  You  may  click  on  the  validation  identifier  below  to  navigate  to  the  "View  Contribution 
Status"  form. 

Validation  ID:  1248207116703 


Transaction  Identifier 


This  number  may  be  used  to  check  the  overall  processing  status  of  your  transaction.  You  may  click  on 
the  transaction  identifier  below  to  navigate  to  the  'View  Contribution  Status"  form. 

Transaction  ID:  1248207117249 


Figure  50  -  A  contribution  result  message 

A  message  similar  to  the  one  in  Figure  50  indicates  that  your  submission  was  accepted 
for  processing.  It  does  not  confirm  that  your  object  was  successfully  registered.  To 
determine  whether  your  object  was  registered,  click  the  transaction  ID  number.  A  screen 
similar  to  the  one  in  Figure  5 1  will  appear.  In  addition,  you  may  want  to  make  note  of  the 
transaction  ID  for  future  reference  (The  screen  in  Figure  51  can  also  be  accessed  by 
selecting  Contribute  from  the  main  menu  on  the  left  side  of  any  page  and  then  selecting 
View  Contribution  Status  from  the  drop-down  menu.) 

NOTE  -  If  you  uploaded  a  large  XML  file  (greater  than  10  MB),  the  ADL  Registry  may  not 
proeess  your  contribution  immediately.  In  this  case,  a  message  similar  to  the  one  in  Figure  50  will 
be  displayed,  but  the  message  will  provide  a  validation  ID  only.  You  can  click  this  ID  to 
determine  if  your  contribution  file  was  accepted  for  processing.  Later,  you  can  check  on  the 
success  of  the  contribution  using  the  transaction  ID  that  was  provided  by  e-mail. 
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View  Contribution  Status 

This  form  provides  status  of  a  contribution  using  either  a  Validation  ID  or  a  Transaction  ID  Click  here 
for  more  information 

User  Name: 

Password: 

fcXQCt  PaSS'A'Qfd'^^ 

Transaction  ID: 

Validation  ID: 

[  »jgew  contribution  status  ] 


11248207117249 


Figure  51  -  The  view  contribution  status  form 

Because  you  accessed  this  form  directly  from  the  Contribution  Results  page,  the 
Transaction  ID  field  was  automatically  completed  for  you.  Enter  your  user  name  and 
password  and  click  »  view  contribution  status.  If  your  submission  was  successful,  you 
will  receive  a  message  similar  to  the  one  shown  in  Figure  52.  If,  instead,  you  receive  a 
message  stating  that  your  submission  failed,  you  can  contact  the  help  desk  to  resolve 
problems  with  the  submission. 


Contribution  Status  Result 


Transaction  Status 


The  information  below  provides  an  overview  of  the  ADL  Registry's  progress  in  validating  your 
submission 

Transaction  ID:  1248718976635 

User  Name:  reviewer 

Group:  4444  grp/testgroup 

Summary:  1  of  1  transaction  operations  have  been  processed  successfully. 

Object  Identifier:  3333/00 

Metadata  Instance  Identifier:  3333/MD001 24871 8977232 

Requested  Operation:  insert 

Status:  success 


Figure  52  -  A  successful  contribution 
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3.5  Getting  help 

The  ADL  Registry  Web  site  provides  several  features  to  help  registry  users.  To  access 
these  features,  select  Help  in  the  main  menu  on  the  left  side  of  any  page. 

3.5.1  Additional  information 

The  first  two  items  in  the  Help  drop-down  menu,  About  ADL  and  About  the  ADL 
Registry,  link  to  the  main  ADL  Web  site  home  page  and  the  ADL  Registry  page  that 
resides  on  the  main  site,  respectively.  These  pages  provide  general  information  about  the 
ADL  project  and  the  ADL  Registry. 

Selecting  ADL  Registry  FAQ  accesses  “Frequently  Asked  Questions  About  the  ADL 
Registry,”  shown  in  part  in  Figure  53.  This  FAQ  provides  information  about  multiple 
topics  of  interest  to  many  registry  users.  Click  on  one  of  the  topics  in  the  list  to  get  more 
information  about  the  topic. 


Frequently  Asked  Questions  About  the  ADL  Registry 

■  what  is  the  ADL  Registry? 

■  What  does  DoDI  1322.26  require  related  to  the  ADL  Registry? 

■  What  does  a  repository  manager  do? 

■  What  is  a  local  digital  object  repository? 

■  How  do  I  register  contributors  for  registered  repositories? 

■  What  types  of  content  should  I  contribute  to  the  ADL  Registry? 

■  What  digital  object  formats  does  the  ADL  Registry  accept? 

■  How  do  I  contribute  metadata  to  the  ADL  Registry? 

■  What  types  of  transactions  can  I  perform  in  the  ADL  Registry? 

■  Where  can  I  view  examples  of  ADL  Registry  transactions  and  schemes? 

■  How  do  I  view  the  status  of  a  contribution? 

■  What  is  the  Practice  ADL  Registry? 

■  How  do  I  perform  a  wildcard  search? 

■  Why  am  I  getting  an  ’invalid  vCard  format  for  contribute  entity"  error? 

■  Why  aren't  the  links  in  the  search  results  working? 

■  How  do  I  use  the  Advanced  Search  Form? 


Figure  53  -  FAQ  topics 

3.5.2  Contacting  the  help  desk 

If  you  have  questions  or  eomments  about  the  ADL  Registry,  seleet  Contact  Us  from  the 
Help  drop-down  menu.  Enter  your  eontaet  information  and  your  question  or  eomment  as 
shown  in  Figure  54  and  cliek  »  submit.  You  will  receive  an  e-mail  confirming  reception 
of  your  question  or  comment,  which  will  be  followed  by  a  response  from  the  help  desk. 
Instead  of  using  the  form,  you  can  call  or  e-mail  the  help  desk  using  the  displayed  contact 
information. 


48 


Contact  Us 

The  ADL  Registry  Help  Desk  welcomes  your  questions,  comments  and  recommendations  Please 
submit  using  the  form  below,  via  e-mail  at  adlrhelodeskfSadlnet  gov,  or  by  calling  1 .888  DOD-ADLR 
(1  888  363  2357). 


Name: 

E-mail  Address: 
Phone  Number: 

Subject: 


Comments:  When  I  submit  metadata  using  an  XML  file,  the  Web 

Site  displays  a  501  error.  Please  explain  what 
could  cause  this  error. 

Regards, 

Joe 


[  »  submit  ] 

Mailing  address: 

ADL  Co-Laboratory  Hub 
1901  N  Beauregard  Street 
Suite  600 

Alexandria  Virginia  22311 


Figure  54  -  The  contact  us  form 

3.5.3  Help  with  user  names  and  passwords 

If  you  have  forgotten  your  user  name  or  password,  seleet  Retrieve  Password  from  the 
Help  drop-down  menu.  Enter  your  name  and  e-mail  address  as  shown  in  Figure  55  and 
eliek  »  retrieve  password.  The  help  desk  will  send  you  an  e-mail  with  your  user  name 
and  a  new,  temporary  password.  You  should  change  the  temporary  password  to  a  new 
permanent  password  (see  Section  3.5.4). 
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Retrieve  Password 

Enter  your  name  and  e-mail  address  to  receive  your  user  name  and  temporary  password 


[  » retrieve  password 


Figure  55  -  Retrieving  a  password 

3.5.4  Changing  a  password 

To  change  your  password,  select  Change  Password  from  the  Help  drop-down  menu.  As 
shown  in  Figure  56,  enter  your  user  name,  eurrent  password,  and  the  new  password  and 
click  »  change  password.  The  new  password  must  conform  to  the  requirements  listed  at 
the  bottom  of  the  form,  or  it  will  not  be  aceepted. 


Change  Password 


Enter  your  user  name,  current  password  and  a  new  password  to  change  the  password  associated  with 
your  ADL  Registry  and/or  Practice  ADL  Registry  accounts 

User  Name: 

Current  Password: 

New  Password: 

Verify  New  Password: 

A  (password  must 

•  be  at  least  8  characters  in  length 

•  hot  contain  any  spaces. 

•  contain  at  least  2  upper  case  characters. 

•  contain  at  least  2  lower  case  characters. 

•  contain  at  least  two  special  characters.  Examples:  !@#$&%? 


[  »  change  password~] 


Figure  56  -  Changing  a  password 
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4  Descriptive  metadata 

ADL  Registry  metadata  is  divided  into  two  eategories.  Descriptive  metadata  describes 
digital  objects.  Transaction  metadata  describes  the  transactions  that  are  used  to  contribute 
objects  and  manipulate  their  descriptive  metadata  records.  This  section  provides  basic 
information  and  guidelines  for  creating  descriptive  metadata.  Section  5  covers  transaction 
metadata.  Volume  3  provides  more  detailed  technical  information  for  both  categories. 

4.1  Creating  descriptive  metadata  for  objects 

Descriptive  metadata  provides  important  information  about  a  digital  object,  such  as  title, 
author,  description,  and  keywords.  It  enables  searchers  to  locate  relevant  objects 
efficiently  and  effectively.  Registering  accurate,  complete  metadata  is  important. 

The  mandatory  metadata  required  by  the  ADL  Registry  to  contribute  a  digital  object  is  a 
subset  of  the  metadata  in  the  IEEE  LOM  standard  [4]  and  has  been  adapted  for  use  by  the 
ADE  community.  Additional  LOM  elements  may  be  used  to  more  fully  describe  objects. 
The  ADL  Registry  indexes  all  metadata  so  that  others  can  find,  share,  reuse,  and 
repurpose  the  objects.  (See  Appendix  B  of  Volume  3  for  a  full  listing  of  LOM  elements.) 

Metadata  also  can  be  used  to  manage  objects  more  effectively  in  a  repository.  ADL 
Registry  metadata  includes  life-cycle  management  elements,  such  as  security  level  and 
access  rights,  that  are  useful  to  those  who  create  and  maintain  objects. 

NOTE  -  In  some  cases,  existing  descriptive  metadata  may  be  available  for  a  digital  object,  such 
as  metadata  within  a  SCORM  package  or  metadata  fields  that  describe  a  photograph.  To  make  it 
useful  to  the  ADL  Registry,  the  contributor  will  need  to  identify  and  map  the  existing  metadata  to 
the  ADL  Registry  mandatory  and  optional  metadata  elements. 

4.1.1  Writing  good  metadata 

To  be  useful,  descriptive  metadata  must  be  thoughtful,  well  written,  and  specific.  Try  to 
anticipate  the  background,  search  habits,  and  common  vocabularies  of  the  community 
likely  to  be  seeking  your  digital  object.  Use  the  most  specific  and  descriptive  terms 
possible.  Metadata  records  are  the  basis  for  ADL  Registry  searches,  so  try  to  anticipate 
how  others  might  pose  their  search  queries. 

Keep  in  mind  that  different  groups  may  describe  the  same  objects  in  different  ways.  Eor 
example,  the  Department  of  Defense  Identification  Code  (DODIC)  applied  to 
ammunition  is  a  4-digit,  alphanumeric  code.  It  is  called  a  DODIC  by  the  Army,  NALC 
(Navy  Ammunition  Logistics  Code)  by  the  Navy,  and  LARC  (Locally  Assigned 
Reporting  Code)  by  the  Air  Eorce.  To  help  individuals  from  each  of  those  branches  find 
objects  concerning  ammunition,  the  organization  that  creates  the  objects  should  include 
the  relevant  terms  used  by  each  of  the  Services  in  both  the  keyword  and  description 
metadata  elements.  Be  careful  when  using  local  acronyms  and  terms. 

Object  developers  may  generate  most  of  the  metadata  about  their  objects,  or  one 
individual  or  group  may  write  all  of  the  metadata  for  the  organization.  Often,  metadata  is 
best  created  by  those  who  develop  objects  because  they  are  most  familiar  with  them. 
However,  local  policy  determines  how  metadata  is  developed  and  managed. 
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4.1.2  Versioning  in  metadata 

A  metadata  record  references  a  single  digital  object.  If,  for  whatever  reason,  you  wish  to 
register  multiple  versions  of  an  object,  each  must  be  registered  as  a  separate  object  and 
have  its  own  unique  metadata  record  in  the  ADL  Registry.  If  you  wish  to  have  only  a 
more  recent  version  of  a  previously  registered  object  represented  in  the  ADL  Registry, 
you  can  update  the  version  information  in  the  registered  object’s  existing  metadata 
record. 

4.1.3  Metadata  eiement  vocabuiaries 

Metadata  elements  are  the  individual  items,  such  as  title  and  description,  that  make  up  the 
descriptive  metadata.  Some  metadata  elements,  such  as  description,  may  contain  any  text 
that  is  appropriate  -  in  this  case,  a  free-form  narrative  describing  the  digital  object.  Other 
elements  have  defined  lists  of  values,  called  vocabularies.  A  vocabulary  may  be  closed  or 
open.  If  an  element  has  a  closed  vocabulary,  you  must  use  one  of  the  choices  provided.  If 
an  element  has  an  open  vocabulary,  you  may  select  a  value  from  the  list  or  provide  your 
own  if  none  of  the  values  are  appropriate. 

For  example,  the  copyright  element  has  a  closed  vocabulary  that  is  limited  to  two  valid 
values:  “yes”  and  “no”.  Any  other  value  will  cause  the  transaction  to  fail  and  report  an 
error.  In  contrast,  the  collection  element  has  an  open  vocabulary  that  includes  the  value 
“DOD”.  Because  the  vocabulary  is  open,  a  value  may  either  be  selected  from  the 
predefined  list,  defined  by  the  contributor,  or  both. 

4.2  Mandatory  descriptive  metadata  eiements 

Table  1  lists  the  descriptive  metadata  elements  that  are  required  by  the  ADL  Registry.  All 
mandatory  elements  must  be  present  with  valid  values;  otherwise,  the  transaction  will 
fail,  and  an  error  will  be  reported.  These  elements  are  mandatory  because  they  have  been 
determined  to  be  the  minimal  set  required  to  adequately  describe  digital  objects  for 
search  purposes  or  they  include  information  that  may  be  important  to  those  who  may 
wish  to  reuse  the  object. 

The  elements  in  Table  1  are  divided  into  four  categories  -  general,  life  cycle, 
classification,  and  other  -  based  on  the  information  they  provide.  The  table  includes  an 
example  based  on  a  HAZMAT  course. 

NOTE  -  Even  if  you  are  updating  an  existing  metadata  record,  you  must  supply  all  mandatory 
elements.  The  existing  record  is  completely  overwritten  by  the  updated  record. 


52 


Table  1  -  Mandatory  descriptive  metadata  elements 


Element 

name 

Description 

Use 

Example 

GENERAL: 

Title 

(Use  once  only) 

A  descriptive  title 
for  the  object. 

If  the  object  has  an  official 
title,  such  as  a  title  that  is 
or  will  be  listed  in  a  course 
catalog,  use  the  official 
title. 

HAZMAT 

Familiarization  &  Safety 
in  Transportation 
(AMMO-67) 

Description 
(Use  once  only) 

A  succinct 
description  of  the 
object  using 
primarily 
searchable  words 
and  phrases. 

Write  a  few  sentences  that 
provide  a  general  overview 
of  the  material  covered  in 
the  object.  If  the  object  is  a 
SCO,  the  description 
provided  within  the  object 
will  usually  suffice  as  the 
value  for  this  element. 

This  course  introduces 
the  regulation  of 
hazardous  materials 
during  transportation, 
including  publications 
that  affect  their 

movement.  It  covers 

visual  identification  of 
HAZMAT  on  packages, 
transport  vehicles,  and 
transportation 
paperwork.  Material 

Safety  Data  Sheets 
(MSDS)  are  explained. 

Use  of  the  Emergency 
Response  Guide  (ERG) 
is  also  covered. 

Keyword 
(Use  one  or 
more) 

Words  or  short 
phrases  used  to 
identify  or  define 
the  object. 

List  words  or  phrases  that 
describe  the  object  in  terms 
familiar  to  the  target 
audience.  At  least  three 
keywords  are 
recommended  and  more 

are  allowed. 

HAZMAT  identification 
transporting  HAZMAT 
MSDS  ERG 

NOTE  -  You  may  enter 
multiple  keywords  using  a 
single  keyword  element. 

LIFE  CYCLE: 

Version 
(Use  once  only) 

The  current  edition 

or  iteration  of  the 
object. 

Specify  the  current  version. 
If  your  organization  does 
not  have  a  defined 
versioning  system,  you 
should  create  one. 

3.0 
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Element 

name 

Description 

Use 

Example 

Status 

(Use  once  only) 

The  current  phase 
of  the  program  for 
which  the  object  is 
being  registered  or 
the  status  of  the 
object. 

Choose  one  of  the 
following  from 

DoDl  1322.20: 

query  only 

proposed  development 
under  development 

development  or 
acquisition  completed 

program  revision 

out  of  service 

program  terminated 

other 

Or  one  of  the  following 
from  IEEE  EOM: 

draft 

final 

revised 

unavailable 

under  development 

Contributor  Role 
(Use  one  or  more 
in  conjunction 
with  Contributor 
Entity) 

The  roles  of  the 
individuals  or 
organizations  that 
contributed  to  the 
object. 

Contributors  are 
named  by  the 
Contributor  Entity 
element. 

You  must  choose  “author” 
at  least  once;  then  you  may 
choose  any  of: 

author 

publisher 

initiator 

terminator 

validator 

editor 

graphical  designer 
technical  implementer 
content  provider 
object  provider 

technical  validator 

educational  validator 

script  writer 
instructional  designer 
subject  matter  expert 

unknown 

author 

validator 

NOTES: 

1 .  Your  metadata  may 
contain  multiple  roles,  and 
each  role  may  contain 
individuals  and 
organizations.  An  author  is 
required,  and  you  may  list 
additional  contributors. 
Vendors  working  for  DoD 
may  want  to  provide  both 
their  corporate  information 
and  the  DoD  Proponent’s 
information.  If  multiple 
roles  are  listed,  this  element 
is  repeated  for  each  role. 

2.  The  role  “content 
provider”  is  provided  for 
compatibility  with  previous 
versions  of  the  ADL 

Registry.  The  role  “object 
provider”  should  be 
preferred. 
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Element 

name 

Description 

Use 

Example 

Contributor 

Entity 

(Use  one  or  more 
in  conjunction 
with  Contributor 
Role) 

Names  and  contact 

information  for 

individuals  and 
organizations  that 
contributed  to  the 
object.  The  roles  of 
contributors  are 
defined  by  the 
Contributor  Role 

element. 

List  each  element  of  the 

contact  information  on  a 
separate  line.  List  at  least 
one  contributor  entity  for 
each  contributor  role  that 
you  listed. 

Defense  Ammunition 
Center  (DAC) 

Directorate  for  Training 

1  C  Tree  Road 

McAlester,  OK  74501 
(918)  420-8961 

sj  mac -ast@dac.  army.mil 

Contribution 

Date 

(Use  once  only) 

The  date  of  the 

contribution. 

Use  the  format: 

YYYY-MM-DD. 

2005-09-30 

CLASSIFICATION: 

Security 
(Use  once  only) 

The  security 
classification  of  the 
object. 

Y ou  must  select: 

unclassified 

unclassified 

NOTE  -  At  this  time  the 
ADL  Registry  permits  the 
registration  of  unclassified 
objects,  only. 

Object  Type 
(Use  once  only) 

The  type  of  object. 

Choose  one  of: 

asset 

SCO 

aggregation 

other 

aggregation 

NOTE  -  Any  object  may 
be  registered;  however, 
only  SCOs  are  required  by 
DoD  policy  to  be 
registered.  An  object  may 
be  an  asset,  such  as  a 
technical  document, 
competency,  or  image,  a 
SCO,  or  an  aggregation  of 
objects,  such  as  multiple 
SCOs  comprising  a 
course.  Use  the  term  that 
best  applies  to  your  object. 
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Element 

name 

Description 

Use 

Example 

Distribution 

Restrictions 
(Use  once  only) 

Any  restrictions  on 
distribution  of  the 
object.  For 
example,  some 
materials  cannot  be 

distributed  to 
foreign  nationals. 

For  objects  used  in 
learning,  use  one  of  the 
following  two-letter  codes 
ffomDoDl  1322.20: 

LR  -  Legal  restrictions  to 
public  distribution 

NR  -  No  legal  restriction 
to  public  distribution 

CP  -  Cleared  for  public 
exhibition  but  not 

distribution 

CG  -  Cleared  for  govern¬ 
ment  distribution  only 

CD  -  Cleared  for  DoD 
distribution  only 

RD  -  Restrictions  to  DoD 

distribution 

NF  -  NOFORN  (i.e.,  not 
available  for  foreign 
nationals) 

OT  -  Other 

For  technical  reports  and 
other  publications,  use  one 
of  the  following  from 

DoDD  5230.24: 

Distribution  Statement  A 

Distribution  Statement  B 

Distribution  Statement  C 

Distribution  Statement  D 

Distribution  Statement  E 

Distribution  Statement  F 

Distribution  Statement  X 

LR 

NOTE  -  If  you  aren’t  sure 
which  code  or  statement  to 
use,  ask  your  repository 
manager  or  security  officer 
for  help.  Determining 
distribution  restrictions  is 
the  responsibility  of  the 
sponsoring  office  (the 
originating  activity). 
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Element 

name 

Description 

Use 

Example 

Compliance 
(Use  one  or 
more) 

The  primary 
specification  or 
standard  that 
applies  to  the 
object.  If 
appropriate, 
multiple 

specifications  may 
be  provided. 

Choose  one  or  more  of: 

SCORM  2004  3rd 

Edition 

SCORM  2004  4th 

Edition 

SCORM  Version  1.2 

SIOOOD  V2.0 

SIOOOD  V2.1 

SIOOOD  V2.2 

SIOOOD  V2.3 

SIOOOD  V3.0 

SIOOOD  V4.0 

IEEE  1484.20.1-2007 

RCD 

other 

none 

SCORM  2004  4th 

Edition 

Collection 
(Use  once  or 
more) 

The  categories  or 
groups  that  may 
find  the  object  to 
be  useful. 

At  minimum,  specify: 

DOD. 

DOD 

NOTE  -  You  may  specify 
additional  applicable 
categories,  such  as  DAC  or 
NAVAIR. 

OTHER  METADATA: 

Metadata 

Schema 
(Use  two  or 
more) 

The  names  and 
versions  of  the 
metadata 

specifications  used 
to  create  the 
metadata. 

You  must  list  at  least: 

ADL-Rvl.O 

LOMvl.O 

ADL-Rvl.O 

LOMvl.O 

NOTE  -  The  metadata  for 
all  ADL  Registry  entries 
must  conform  to  both  the 
LOM  standard  and  the 

ADL  Registry  Metadata 
Version  1.0  specification  in 
Volume  3.  Your  metadata 
may  conform  to  additional 
metadata  schemas,  such  as 
the  MedBiquitous 

Healthcare  schema.  List  all 
relevant  metadata  schemas. 
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Element 

name 

Description 

Use 

Example 

Format 
(Use  one  or 
more) 

The  format  types 
of  files  contained 
in  the  object. 

These  values  map  to 
specific  Multipurpose 
Internet  Mail  Extensions 
(MIME)  types.  Eist  the 
MIME  type  for  every  file 
used  in  the  object. 

video/mpeg 

text/html 

image/jpeg 

image/gif 

audio/mpeg 

NOTES: 

1 .  A  reference  for  MIME 
types  can  be  found  at 
http://www.w3  schools. com/ 
media/media  mimerefasp. 

2.  The  value  “non-digital” 
is  allowed  for  objects  that 
are  not  available  for 
downloading,  such  as  a 
course  that  is  available  only 
on  CD. 

Copyright  and 
Other 

Restrictions 
(Use  once  only) 

Identifies  whether 
there  are  copyright 
or  other 

restrictions  on  use 
of  or  access  to  the 
object. 

Choose  one  of  the 
following: 

yes 

no 

yes 

NOTE  -  Choosing  “yes” 
does  not  preclude  others 
from  sharing  your  object.  It 
simply  informs  them  that 
restrictions  exist.  Generally, 
a  searcher  would  contact 
the  author  to  discuss  any 
restrictions. 

4.3  Optional  metadata  elements  and  extensions 

ADL  Registry  mandatory  descriptive  metadata  is  a  specific  subset  of  the  IEEE  EOM 
standard  [4]  combined  with  specific  usage  requirements,  such  as  ADE-specific 
vocabularies.  However,  this  mandatory  subset  should  not  prevent  you  from  adding  more 
metadata  to  be  used  internally  by  digital  object  creators  and  maintainers  or  to  enable 
more  accurate  discovery  of  relevant  objects. 

Any  additional  metadata  elements  must  be  defined  by  the  IEEE  EOM  standard  (see 
Appendix  B  of  Volume  3).  The  ADE  Registry  does  not  allow  the  addition  of  new 
elements  as  extensions  to  the  standard. 

The  IEEE  EOM  standard  includes  many  elements  that  can  be  used  for  many  different 
purposes.  When  non-mandatory  EOM  elements  are  used,  their  use  should  be  documented 
to  ensure  consistency  across  your  organization.  This  practice  will  promote  consistency 
and  quality  across  multiple  developers  in  a  local  community  of  practice. 
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5  Transactions  and  transaction  metadata 

This  section  gives  more  detail  on  the  registry  transactions  that  are  available  to  manage 
metadata  records  and  the  transaction  metadata  that  is  required. 

5.1  The  insert  transaction  in  detail  -  digital  object 
registration 

As  previously  stated,  the  ADL  Registry  is  not  an  object  repository.  Instead,  it  uses 
metadata  to  identify  and  describe  objects  in  specific  repositories  within  the  ADL 
community.  Objects  are  registered  by  “inserting”  associated  metadata  records  into  the 
ADL  Registry.  Figure  57  summarizes  the  steps  involved. 


Figure  57  -  The  registration  process 

5.1.1  Selecting  an  object  for  registration 

Object  selection  is  the  first  step  a  contributor  must  take  to  register  metadata  for  a  digital 
object.  Because  the  ADL  Registry  stores  metadata  only,  it  does  not  restrict  the  sizes  or 
types  of  objects  being  registered.  The  only  requirement  placed  on  a  repository  in 
registering  its  objects  is  that  it  must  provide  some  means  to  retrieve  them.  The  repository, 
of  course,  retains  control  over  local  retrieval  policies. 

For  example,  a  repository  manager  may  manage  a  set  of  SCORM  2004  [7]  packages 
stored  on  a  local  file  server.  Network  policies  could  prevent  external  access  to  the  server. 
In  this  case,  their  location  might  resolve  to  a  Web  page  that  provides  contact  information 
instead  of  a  direct  link  for  downloading  packages. 

5.1.2  Defining  descriptive  metadata 

After  selecting  a  digital  object  for  registration,  the  next  step  descriptive  metadata 
creation.  Descriptive  metadata  is  discussed  in  detail  in  Section  4. 

5.1.3  Registering  the  object 

Once  the  digital  object  has  been  selected  and  its  descriptive  metadata  has  been  defined  as 
described  in  Section  4,  the  object  is  registered  using  an  insert  transaction.  The  ADL 
Registry  provides  two  means  for  submitting  registry  transactions; 

1 .  Manually  through  the  ADL  Registry  Web  site,  which  requires  either  completing  a 
submission  form  or  uploading  an  XML  file. 
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2.  Automatically  using  an  application  that  interfaces  with  the  ADL  Registry,  whieh 
requires  a  custom  application  that  uses  the  RIM-Lite  interfaee  (see  Volume  3). 

Each  registry  transaction  includes  information  that  informs  the  ADL  Registry  about  the 
submission  and  the  contributor.  Mandatory  information  includes 

•  The  identifier  of  the  contributor  making  the  submission. 

•  The  identifier  of  the  group  the  contributor  is  acting  under. 

•  A  time  stamp  for  the  submission. 

•  The  ADL  Registry  operation  being  applied  (such  as  insert). 

•  An  objeet  ID  and  a  repository  ID  (handles).  Some  transaetions  also  require  a 
metadata  instance  ID. 

•  The  location  from  where  the  digital  object  can  be  retrieved. 

•  The  descriptive  metadata  being  submitted. 

NOTE  -  To  register  an  object  using  an  XML  file,  the  descriptive  metadata  must  be  formatted  as 
XML  [9].  Then,  additional  information  that  tells  the  ADL  Registry  how  to  complete  the 
registration  is  added.  This  information  -  or  transaction  metadata  -  is  also  formatted  as  XML  and 
is  called  a  transaction  envelope  (see  Section  5.3). 

5.1.4  Checking  registration  status 

Regardless  of  the  means  used  to  submit  a  registry  transaetion,  the  ADL  Registry  will 
proeess  the  transaction  and  feed  back  the  results  of  that  proeessing.  The  ADL  Registry 
provides  feedback  in  two  parts; 

1 .  Validation:  The  ADL  Registry  provides  immediate  results  regarding  the 
contributor’s  authorization  and  access  rights  to  perform  the  operation  deseribed  in 
the  registry  transaetion  and  validates  the  transaetion.  If  the  transaetion  appears 
eomplete  and  valid,  the  eontributor  is  provided  a  transaction  ID  that  may  be  used 
to  eheck  the  status  of  objeet  registration. 

2.  Registration:  After  a  registry  transaction  has  been  validated,  the  ADL  Registry 
indexes  and  stores  the  objeet’s  metadata.  This  may  happen  immediately  after 
validation  in  the  case  of  the  online  form  or  the  uploading  of  a  small  XML  file,  or 
it  may  involve  some  delay  in  the  case  of  a  large  XML  file  (typically  files  of 

10  MB  or  more.) 

The  eontributor  can  obtain  the  status  of  a  registry  transaetion  at  any  time  by  providing  the 
submission’s  transaction  ID,  which  is  provided  by  the  ADL  Registry  Web  site  after  a 
manual  submission  or  by  the  RIM-Lite  interface  after  an  automatic  submission.  As  with 
submitting  a  registry  transaction,  the  eontributor  has  two  means  to  obtain  transaetion 
status:  either  manually  through  the  ADL  Registry  Web  site  or  automatically  using  RIM- 
Lite.  In  both  cases,  the  ADL  Registry  will  respond  with  the  status  of  the  transaetion. 
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If  the  ADL  Registry  fails  to  process  a  transaction,  information  contained  in  the 
transaction  status  may  be  used  to  help  determine  the  point  and  cause  of  the  failure. 
Generally,  problems  will  fall  into  three  categories: 

1.  Authentication/authorization  error:  The  contributor  has  provided  incorrect 
identification  information  or  is  not  permitted  to  perform  the  operation. 

2.  Metadata  error:  The  object’s  metadata  is  invalid,  is  missing  a  mandatory 
element,  or  one  of  its  elements  violates  a  business  rule. 

3.  Registry  transaction  error:  Information  in  the  transaction  envelope  is  either 
missing  or  improperly  formatted. 

See  Section  6  for  more  information  on  common  errors. 

5.2  Transaction  overview 

This  section  gives  an  overview  of  the  transactions  supported  by  the  ADL  Registry. 
Detailed  information  on  transactions  including  examples  of  transaction  files  is  available 
in  Volume  3. 

5.2.1  Inserting  a  metadata  record 

Transaction  name:  insert 

This  transaction  inserts  a  new  metadata  record  that  describes  a  digital  object.  It  is  the 
most  common  transaction  type  and  is  used  for  contributing  new  objects  as  well  as  adding 
new  metadata  records  for  previously  registered  objects.  The  inserted  metadata  record  is 
assigned  a  metadata  instance  ID  and  can  be  retrieved  through  the  ADL  Registry. 

NOTE  -  If  you  are  adding  a  new  metadata  record  for  an  object  that  has  already  been  registered, 
do  not  include  an  object  location  (URL).  This  will  result  in  an  error  (see  Section  6). 

5.2.2  Updating  a  metadata  record 

Transaction  name:  update 

This  transaction  updates  a  previously  registered  metadata  record.  The  transaction  replaces 
the  entire  existing  metadata  record  with  the  new  record.  The  XML  file  must  contain  a  full 
set  of  metadata,  including  elements  that  will  not  change  with  the  update.  The  updated 
metadata  record  retains  its  original  metadata  instance  ID. 

5.2.3  Deleting  a  metadata  record 

Transaction  name:  delete 

This  transaction  deletes  an  existing  metadata  record.  If  more  than  one  metadata  record 
exists  for  a  digital  object,  only  the  record  identified  by  its  metadata  instance  ID  will  be 
deleted.  Any  search  for  the  object  that  uses  metadata  defined  in  the  deleted  metadata 
record  will  fail. 
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5.2.4  Deactivating  a  metadata  record 

Transaction  name;  deactivate 

This  transaction  disables  searches  based  on  an  existing  metadata  record  until  further 
notice.  Any  search  for  the  digital  object  that  uses  metadata  defined  in  the  deactivated 
metadata  record  will  fail.  In  addition,  the  record  cannot  be  retrieved  using  its  metadata 
instance  ID.  If  more  than  one  metadata  record  exists  for  an  object,  only  the  identified 
metadata  record  will  be  deactivated. 

You  might  want  to  deactivate  a  metadata  record  during  updates  to  its  associated  object  or 
if  the  object  is  no  longer  in  use,  but  you  want  to  maintain  a  record  of  its  existence  within 
the  ADL  Registry. 

5.2.5  Activating  a  metadata  record 

Transaction  name;  activate 

This  transaction  enables  searches  based  on  a  previously  deactivated  metadata  record.  Any 
search  for  the  digital  object  that  uses  metadata  defined  in  the  reactivated  record  will 
succeed.  If  more  than  one  deactivated  record  exists  for  an  object,  only  the  identified 
metadata  record  will  be  reactivated. 

5.2.6  Moving  a  digital  object’s  location 

Transaction  name;  move 

This  transaction  informs  the  ADL  Registry  that  one  or  more  of  the  locations  for  a 
registered  digital  object  have  changed.  All  search  results  that  return  the  object  will  reflect 
the  new  locations. 

5.2.7  Withdrawing  all  metadata  records 

Transaction  name;  withdraw 

Unlike  delete  or  deactivate,  this  transaction  removes  all  registered  metadata  records 
describing  a  digital  object  identified  by  its  digital  object  ID.  All  searches  for  the  object 
will  fail  because  it  will  no  longer  be  registered. 

5.3  Transaction  metadata 

A  transaction  envelope  contains  transaction  metadata  that  identifies  the  contributor  and 
describes  the  transaction  to  be  performed  by  the  ADL  Registry.  Table  2  lists  the 
transaction  metadata  elements,  describes  their  use,  and  includes  a  hypothetical  example. 
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Table  2  -  Transaction  metadata 


Element 

name 

Description 

Use 

Example 

Version 

The  major 
version  of  the 
ADL  Registry 
with  which  the 
envelope 
complies. 

This  value  must  be: 

adlrt-vl.O 

adlrt-vl.O 

Submitter 

Identifier 

Specifically 
identifies  a 

contributor. 

Enter  the  user  name  that  you 
received  after  you  registered 
as  a  contributor  to  the  ADL 
Registry. 

jsmithOOl 

NOTE  -  The  ADL  Registry  uses 
the  Submitter  Identifier  to 
authorize  the  contributor. 

Group 

Identifier 

The  contributor 
group  in  which 
the  contributor 

is  enrolled. 

Enter  the  contributor  group 

ID  that  was  provided  by  your 
repository  manager. 

4444.grp/navsearepository00 1 

NOTE  -  Contributors  are 
members  of  larger  groups  of 
registrants.  Transaction  rights  are 
assigned  to  groups  and 
determined  by  group  membership 
(see  Section  3.3). 

Transaction 

Action 

The  action  the 
ADL  Registry 
should  take. 

Choose  one  of  the  following 
actions.  The  actions  are 

described  in  Section  5.2. 

insert 

update 

deactivate 

activate 

delete 

withdraw 

move 

insert 

Object 

Identifier 

A  unique 
identifier 
assigned  to  the 
object. 

Enter  an  identifier  composed 
of  the  object’s  repository 
prefix  followed  by  a  unique 
local  name  (see  Section  2.6). 

1 00.50. 10.1/sonarcoursel 
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Element 

name 

Description 

Use 

Example 

Location 
Type 
(Use  zero 
or  more  in 
conjunction 
with 
Location 
Value) 

The  type  of 
location  (URL) 
you  are 
providing  for 
the  object.  The 
actual  URLs 
are  specified  by 
the  Location 
Value  element. 

For  inserting  a  new  object  or 
for  updating  or  moving  an 
existing  object,  enter  at  least 
one  of  the  following  URL 
types.  Otherwise,  leave  this 
element  blank,  or  you  will 
receive  an  error.  Only  one  of 
each  type  is  allowed. 

object 

advertisement 

runtime 

contact 

extended  metadata 

repository 

object 

contact 

NOTE  -  URL  types  are  described 
in  Section  3. 1.2.1.  If  possible,  the 
object  URL  type  should  be 
included. 

Location 

Value 

(Use  one  in 

conjunction 

with  each 

Location 

Type) 

A  location 
(URL)  for  a 
specified 
location  type. 

Enter  one  URL  for  each  type 
you  specified  with  the 

Location  Type  element. 

http  ://navsearepository/ 
downloads/sonarcours  1  .zip 

http://navsearepository/ 

contact.html 

Repository 

Identifier 

Identifies  the 
repository 
containing  the 
object. 

Enter  the  repository  ID  that 
was  provided  by  your 
repository  manager. 

100.5 1/navsearepository 

Metadata 

Instance 

Identifier 

Identifies  the 
metadata 
record  that 
describes  the 
object. 

For  update,  delete,  deactivate, 
and  activate  transactions, 
enter  the  metadata  instance 

ID  that  the  ADE  Registry 
assigned  to  the  metadata 
record  after  the  object  was 
initially  registered.  For  insert, 
move,  and  withdraw 
transactions,  leave  this 
element  blank,  or  you  will 
receive  an  error. 

100.3/MDsonarcoursel  1 1943 

Time 

Stamp 

The  date  and 
time  when  this 
transaction  was 
created. 

Unless  a  special  circumstance 
exists,  use  the  current  time. 

2006-04-26T09:51:50 

NOTE  -  Transaction  operations 
are  time-stamp  sensitive.  If  the 
transaction  is  manipulating  an 
existing  record,  the  time  stamp  of 
this  transaction  must  be  more 
recent  than  the  time  stamp  for  the 
existing  record. 
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Element 

name 

Description 

Use 

Example 

Metadata 

Schema 

The  schema 
that  can  be 
used  to  validate 
the  object’s 
metadata. 

This  value  should  be: 

http://hdl.cordra.net/2000. 2/ 
adlreg-lom 

http://hdl.cordra.net/2000. 2/ 
adlreg-lom 

6  Common  errors 

Table  3  describes  common  errors  that  may  be  encountered  by  contributors.  Appendix  C 
of  Volume  3  gives  a  complete  error  listing. 

Table  3  -  Common  transaction  errors 


Error 

Description 

Resolution 

501: 

Principal 

authentication  error 

Occurs  when  you  use  the  wrong 
user  name,  password,  or  both. 

Verify  that  you  are  using  the 
correct  username  and  password. 

See  Section  3.5.3  for  information 
about  retrieving  your  user  name 
and/or  password. 

1002: 

User  group  not 
authorized  to  perform 
transaction 

Occurs  when  you  are  a  member 
of  the  contributor  group  and  try 
to  perform  a  transaction  (delete, 
withdraw,  or  move)  that 
requires  membership  in  the 
manager  group. 

If  you  believe  that  you  should  be  a 
member  of  the  manager  group, 
contact  your  repository  manager, 
who  will  verify  your  group 
membership  with  the  ADL 

Registry  Help  Desk. 

1006: 

Invalid  repository 
specified 

Occurs  when  you  submit  a 
transaction  that  contains  an 
invalid  repository  ID  or  group 

ID.  If  a  submission  contains 
multiple  transactions,  only  the 
transaction  containing  the 
invalid  ID  fails. 

Resubmit  the  transaction  with  the 
correct  ID. 

22503: 

Object  location  should 
not  be  specified 

Occurs  when  you  include  a 
location  (URL)  for  a  transaction 
other  than  insert,  move,  or 
update  or  for  a  second  insert 
transaction  for  an  object  that  has 
already  been  registered  and  has 
not  subsequently  been  deleted. 

Resubmit  the  transaction  without 
an  object  location  (see  Section  5.3). 
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Error 

Description 

Resolution 

24001: 

Error  parsing  XML 

Occurs  when  an  XML  file  is 
invalid.  Invalid  XML  may  be 
malformed  or  may  use  a 
character  encoding  that  is  not 
supported  by  the  ADL  Registry. 
All  transaction  fdes  must  use 
UTL-8  for  encoding  characters. 
This  is  the  default  encoding  for 
XML. 

To  resolve  a  malformed  XML 
issue,  verify  that  your  XML  file 
complies  with  the  XML  binding  for 
a  registry  transaction  and  the  ADL 
Registry  profile  of  LOM  (see 
Volume  3). 

To  resolve  a  character  encoding 
issue,  follow  your  XML  editor’s 
instructions  for  setting  UTL-8 
character  encoding. 

26001: 

Invalid  transaction  ID 

Occurs  when  you  request  the 
processing  status  of  a  given 
transaction  and  specify  an 
invalid  transaction  ID. 

Verify  that  the  transaction  ID  you 
entered  matches  the  transaction  ID 
that  was  provided  for  the  initial 
transaction.  If  the  transaction  ID  is 
correct  and  this  error  persists, 
contact  the  ADL  Registry  Help 

Desk. 

7  Acronyms  and  abbreviations 


ADL 

Advanced  Distributed  Feaming 

ATC 

Air  Traffic  Control 

CD 

compact  disk 

CNRI 

Corporation  for  National  Research  Initiatives 

CORDRA 

Content  Objeet  Discovery  and  Registration/Resolution  Arehitecture 

DAC 

Defense  Ammunition  Center 

DoD 

Department  of  Defense 

DoDD 

Department  of  Defense  Direetive 

DODI 

Department  of  Defense  Instruction 

DODIC 

Department  of  Defense  Identification  Code 

DSN 

Defense  Switehed  Network 

ERG 

Emergeney  Response  Guide 

FAA 

Federal  Aviation  Administration 

FAR 

Federal  Aequisition  Regulation 

FAQ 

Frequently  Asked  Questions 
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HAZMAT 

hazardous  materials 

ID 

identifier 

IDA 

Institute  for  Defense  Analyses 

IEEE 

Institute  of  Electrieal  &  Eleetronics  Engineers 

EARC 

Eoeally  Assigned  Reporting  Code 

EOM 

Eearning  Objeet  Metadata 

MIME 

Multipurpose  Internet  Mail  Extensions 

MSDS 

Material  Safety  Data  Sheet 

NAEC 

Navy  Ammunition  Eogisties  Code 

NAVAIR 

Naval  Air  Systems  Command 

PDE 

Portable  Data  Eormat 

RIM 

registry  interfaee  mechanism 

SCO 

SCORM  object 

SCORM 

Shareable  Content  Object  Reference  Model 

URE 

Uniform  Resource  Eocator 

UTE 

Unicode  Transformation  Eormat 

XME 

Extensible  Markup  Eanguage 
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Appendix  B.  Advanced  searches  and  field 

reference 

The  ADL  Registry  Web  site  supports  advanced  searching  capabilities,  including 
operators  to  restrict  or  expand  searches  and  searches  restricted  to  specific  search  fields. 
This  appendix  explains  advanced  searches  for  users  who  wish  to  go  beyond  simple 
searches  for  metadata  records.  It  also  includes  a  field  reference  for  all  fields  that  are 
searchable  in  the  ADL  registry. 

NOTE  -  The  Web  site  includes  an  advanced  search  form  that  will  satisfy  the  needs  of  many  users 
(see  Section  3.1.4  and  Figure  15). 

B.1  Advanced  searches 

This  section  explains  advanced  searches.  It  includes  mandatory  and  optional  metadata; 
normalization;  terms,  phrases,  and  fields;  and  operators. 

B.1.1  Mandatory  and  optional  metadata 

Metadata  records  submitted  to  the  ADL  Registry  must  include  a  set  of  16  mandatory 
descriptive  metadata  elements,  such  as  title,  description,  and  keywords  (see  Section  4.2). 
Records  may  contain  optional  descriptive  elements,  such  as  intended  end  user  role  and 
context  (see  Appendix  B  of  Volume  3).  By  default,  only  the  mandatory  elements  are 
searched.  To  search  the  optional  elements,  a  search  must  specify  the  optionalText  field 
(see  Section  B.2.1). 

B.1.2  Normalization 

To  make  searching  more  effective,  the  ADL  Registry  automatically  normalizes  certain 
metadata  elements  except  those  that  use  predefined  vocabularies.  Other  elements,  such  as 
predefined  vocabulary  tokens,  are  not  normalized.  Normalization  includes  converting 
characters  to  lower  case  and  removing  common  word  endings.  Converting  characters  to 
lower  case  provides  case  insensitivity.  Removing  word  endings  provides  insensitivity  to 
qualities  such  as  pluralization  and  tense.  This  is  done  by  stemming  or  stripping  suffixes 
(-es,  -s,  -ed,  -ing,  -ate,  -ble,  -ize,  -al,  -ance,  -ence,  -er,  -ic,  -able,  -ible,  -ant,  -ment,  -ism, 
-ous,  -ive,  -ize,  -e),  depending  on  the  structure  of  the  word.  For  example,  a  search  for 
“wound”  also  might  return  results  containing  “wounded”  and  “wounds,”  because  both 
are  stemmed  to  “wound”  at  the  time  of  indexing. 
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B.1.3  Terms,  phrases,  and  fields 

A  search  includes  one  or  more  terms  and  phrases.  A  term  is  a  single  word,  such  as 
“airplane”  or  “pilot.”  Terms  are  separated  by  spaces,  and  each  term  in  a  search  is 
considered  individually  while  building  a  result  set.  A  search  may  specify  that  a  metadata 
record  must  contain  all  of  the  terms  or  that  it  may  contain  any  of  the  terms.  Both  of  the 
following  searches  specify  that  a  record  must  contain  all  three  terms  in  no  particular 
order: 

airplane  pilot  training 
airplane  AND  pilot  AND  training 

The  following  search  specifies  that  a  record  may  contain  one  or  more  of  the  terms: 
airplane  OR  pilot  OR  training 

Terms  are  combined  into  phrases  using  double  quotes.  A  phrase  is  processed  as  though  it 
is  a  single  term.  The  following  search  specifies  that  a  record  must  contain  the  exact 
phrase  “airplane  pilot  training”: 

“airplane  pilot  training” 

Terms  and  phrases  are  case  insensitive.  For  example,  the  phrases  “Airplane  Pilot”  and 
“airplane  pilot”  are  equivalent. 

Searches  can  be  restricted  to  specific  fields,  such  as  title,  keyword,  or  description  (as 
shown  later  in  Table  B.2),  that  correspond  to  specific  metadata  elements  by  specifying  a 
field  name  ending  with  a  colon  and  an  optional  space  followed  by  the  search  expression. 
By  default,  when  no  field  is  specified,  all  mandatory  metadata  elements  are  searched.  The 
following  search  searches  for  objects  with  “HAZMAT”  in  their  titles: 

title:  hazmat 

Fields  are  covered  in  more  detail  in  Section  B.2. 

B.1.4  Operators 

Operators  expand  search  capabilities  by  adding  functionality,  such  as  requiring  or 
excluding  specific  terms  and  grouping  terms.  The  operators  supported  by  the  ADL 
Registry  Web  site  are  listed  in  Table  B.l  and  discussed  in  the  following  sections. 
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Table  B.1  -  Operators  supported  by  the  ADL  Registry  Web  site 


Character 

Meaning 

Usage 

Logical  operators: 

+ 

Requires  a  term  to  be  present. 

-tairplane  -l-pilot 

&& 

airplane  &&  pilot 

AND 

airplane  AND  pilot 

- 

Excludes  a  term  from  being  present. 

airplane  -pilot 

! 

airplane  Ipilot 

NOT 

airplane  NOT  pilot 

II 

Specifies  that  one  term  or  another  may  be  present. 

airplane  pilot 

OR 

airplane  OR  pilot 

Wildcard  operators: 

? 

Matches  exactly  one  character  when  used  within  a  term. 
Matches  zero  or  one  characters  when  used  at  the  end  of 
a  term. 

airpla?e 

* 

Matches  zero  or  more  characters. 

airpl*e 

Range  operators: 

[TO] 

Specifies  an  inclusive  range  search. 

[2006  TO  2007] 
[airplane  TO  pilot] 

{TO} 

Specifies  an  exclusive  range  search. 

(2005  TO  2008} 

(a  TO  d} 

Miscellaneous  operators: 

0 

Groups  two  or  more  terms. 

(airplane  pilot) 

A 

Increases  the  relevance  of  a  term. 

airplane'^  10  pilot 

(.(.  ')•) 

Surrounds  two  or  more  terms  to  create  a  phrase. 

“airplane  pilot” 

Specifies  either  a  fuzzy  search  or  a  proximity  search. 

airplane- 
“airplane  pilot”~5 

Separates  a  field  name  and  a  term  or  phrase  for  field- 
specific  searches. 

title:  airplane 
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NOTE  -  Special  characters  in  quoted  phrases  are  ignored.  The  following  searches  are  equivalent: 


“is  it  a  plane” 

“is  it  a  plane?” 

“is  it  a  (plane)” 

B. 1.4.1  Logical  operators 

Logical  operators  specify  how  search  terms  and  phrases  are  combined  to  constrain  or 
expand  searches.  For  example,  in  a  search  that  includes  two  terms,  an  operator  may  be 
used  to  require  or  exclude  the  second  term  or  to  specify  that  a  metadata  record  may 
contain  either  of  the  two  terms.  The  default  operator  AND  is  used  to  combined  terms 
when  no  operator  is  provided. 

Examples: 

The  following  searches  are  equivalent.  Both  “airplane”  and  “pilot”  must  be  present  in  the 
record. 

Tairplane  +pilot 
airplane  &&  pilot 
airplane  AND  pilot 
airplane  pilot 

The  following  searches  are  equivalent.  The  record  must  contain  “airplane”  and  must  not 
contain  “pilot.” 

airplane  -pilot 
airplane  Ipilot 
airplane  NOT  pilot 

Because  of  the  way  searches  that  use  NOT  operators  are  processed,  the  following 
searches  are  equivalent.  They  return  records  that  do  contain  “airplane”  and  do  not  contain 
either  “pilot”  or  “navigator.” 

airplane  Ipilot  [navigator 
airplane  Ipilot  AND  [navigator 
airplane  [pilot  OR  [navigator 

The  following  searches  are  equivalent.  The  record  may  contain  “airplane”  or  “pilot”  or 
both. 


airplane  ||  pilot 
airplane  OR  pilot 
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Logical  operators  may  precede  phrases.  The  following  seareh  returns  reeords  that  contain 
“hazmat”  but  do  not  contain  the  phrase  “commereial  air”: 

hazmat  [“commercial  air” 

NOTES: 

1.  AND,  OR,  and  NOT  must  be  capitalized  to  be  interpreted  as  operators. 

2.  The  characters  “+”,  and  “!”  must  directly  precede  search  terms  with  no  intervening  spaces; 
for  example,  “+pilof  ’  not  “+  pilot”. 

3.  If  the  second  term  in  a  search  uses  the  “+”  operator,  the  operator  also  must  precede  the  first 
term  to  require  that  term.  For  example,  the  search  “airplane  +pilot”  returns  all  records  that  contain 
“pilot”  regardless  of  whether  they  contain  “airplane,”  but  records  that  contain  both  terms  are 
listed  first. 

4.  A  search  that  uses  only  some  form  of  the  NOT  operator  always  returns  no  results.  For  example, 
the  search  “[airplane  [pilot”  returns  no  results.  It  does  not  return  all  records  that  do  not  contain 
“airplane”  and  “pilof ’. 

5.  The  ADF  Registry  RIM-Fite  interface  for  tool  builders  uses  OR  instead  of  AND  as  the  default 
operator. 

B. 1.4.2  Wildcard  operators 

Wildcard  operators  match  unspecified  eharacters  in  a  term.  A  question  mark,  “?”, 
matches  exactly  one  character  when  used  within  a  term  and  zero  or  one  characters  when 
used  at  the  end  of  a  term.  An  asterisk,  matehes  zero  or  more  characters. 

Examples: 

The  following  seareh  matehes  “plan,”  “plane,”  “plank,”  and  “plant”: 
plan? 

The  following  search  matches  “plane,”  “place”,  and  “plate”: 
pla?e 

The  following  search  matches  “air,”  “airy,”  “airplane,”  “airport,”  and  “Airedale”: 
air* 

NOTE  -  A  wildcard  may  not  be  used  at  the  beginning  of  a  seareh  term.  For  example,  a 
seareh  for  ?est  or  *plane  results  in  an  error. 
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B. 1.4.3  Range  operators 

Range  operators  are  used  to  search  for  records  that  occur  within  specific  numeric  and 
alphabetic  ranges.  Range  searches  may  be  inclusive  or  exclusive.  An  inclusive  range 
search  includes  the  outer  bounds  of  the  range.  An  exclusive  range  search  does  not. 

Inclusive  range  searches 

An  inclusive  range  search  uses  square  brackets,  “[  ]”,  to  enclose  the  range  values  and  TO 
to  separate  the  values.  The  specified  values  are  included  in  the  results.  For  example,  the 
following  search  matches  “a,”  “b,”  “c,”  and  “d”: 

[a  TO  d] 

The  following  searches  are  additional  examples  of  inclusive  range  searches: 

[1  TO  9] 
title:  [1  TO  9] 

date:  [20071201  TO  20071215] 

Exclusive  range  searches 

An  exclusive  range  search  uses  curly  brackets,  “{  to  enclose  the  range  values  and  TO 
to  separate  the  values.  The  specified  values  are  excluded  from  the  results.  For  example, 
the  following  search  matches  “b”  and  “c”  but  not  “a”  or  “d”: 

{a  TO  d} 

The  following  searches  are  additional  examples  of  exclusive  range  searches: 

{1  TO  9} 
title:  {1  TO  9} 

date:  {20071201  TO  20071215} 

NOTES: 

1 .  Because  metadata  is  converted  to  lower  case  during  indexing,  alphabetic  range  values  must  be 
specified  in  lower  case  to  function  properly.  Specifying  part  or  all  of  an  alphabetic  range  in  upper 
case  will  return  no  results  or  unexpected  results. 

2.  Dates  must  be  specified  in  the  format  YYYYMMDD. 

3.  More  complex  range  searches,  such  as  the  following  example,  are  accepted.  Flowever,  results 
are  unpredictable. 

title:  [airplane  TO  pilot] 
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B. 1.4.4  Miscellaneous  operators 

Miscellaneous  operators  include  operators  for  grouping  search  terms,  increasing  the 
relevance  of  a  seareh  term,  and  performing  fuzzy,  proximity,  and  field  searehes.  These 
operators  are  discussed  below. 

Grouping 

Grouping  operators,  “(  )”,  eombine  multiple  seareh  terms,  phrases,  and  operators  to  form 
more  specifie  searehes.  The  following  seareh  eould  be  used  to  find  digital  objeets  related 
to  pilot  training  for  the  F16  or  F18: 

(FI 6  OR  FI 8)  AND  (pilot  AND  training) 

Terms  may  be  grouped  to  seareh  specific  fields.  To  limit  the  seareh  above  to  the  title 
field,  use  the  following  search: 

title:  ((FI 6  OR  FI 8)  AND  (pilot  AND  training)) 

Omitting  the  outermost  parentheses  in  the  seareh  above  changes  its  meaning.  The 
following  seareh  searehes  the  title  field  for  “FI 6”  or  “FI 8”  and  all  mandatory  metadata 
fields  for  “pilot”  and  “training”: 

title:  (FI 6  OR  FI 8)  AND  (pilot  AND  training) 

NOTE  -  The  examples  above  include  AND  for  clarity,  but  the  operator  may  be  omitted  because  it 
is  the  default. 

Relevance 

The  relevance  operator,  increases  the  relevance  of  a  seareh  term.  Reeords  eontaining 
the  more  relevant  term  are  displayed  earlier  in  the  search  results.  The  following  seareh 
returns  reeords  that  eontain  either  “airplane”  or  “pilot”  or  both,  but  reeords  containing 
“pilot”  are  given  more  relevance  in  the  order  of  the  displayed  search  results: 

airplane  OR  piloOlO 

The  value  following  the  operator  must  be  greater  than  zero  and  10  at  most.  Higher  values 
inerease  the  relevanee  of  the  associated  term. 

Fuzzy  searches 

A  tilde,  appended  to  a  seareh  term  searches  for  word  variations.  This  is  called  a 
fuzzy  seareh  and  may  be  useful  when  a  word  may  have  multiple  spellings  or  when  you 
are  uncertain  of  a  word’s  exact  spelling.  The  following  seareh  might  return  reeords 
eontaining  “saber,”  “sabre,”  and  “sober”: 

saber-- 
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Proximity  searches 

Proximity  searches  limit  results  to  words  that  occur  within  a  specified  distance  of  each 
other.  A  proximity  search  consists  of  two  or  more  terms  in  quotes  followed  by  a  tilde, 
and  a  numeric  value.  The  following  search  limits  results  to  records  that  contain 
“airplane”  followed  by  “pilot”  within  five  words: 

“airplane  pilot”~5 

Field  searches 

The  field  operator,  followed  by  an  optional  space  specifies  that  only  a  specific  field, 
such  as  the  title,  is  searched.  Field  names  must  be  entered  in  lower  case.  The  following 
search  returns  records  that  include  “hazmat”  in  their  titles: 

title:  hazmat 

Phrases  in  field  searches  must  be  included  in  quotes  or  all  but  the  first  term  will  be 
treated  as  general  search  terms.  The  following  search  returns  records  that  contain  the 
phrase  “hazmat  familiarization”  in  their  titles: 

title:  “hazmat  familiarization” 

Without  the  quotes,  the  following  search  returns  records  that  include  “hazmat”  in  their 
titles  and  “familiarization”  in  any  required  field: 

title:  hazmat  familiarization 

Search  terms  may  be  grouped.  The  following  searches  are  equivalent  and  return  records 
that  include  “airplane”  and  “pilot”  in  any  order  in  the  title  field: 

title:  (airplane  pilot) 
title:  (airplane  AND  pilot) 

The  following  search  returns  records  that  contain  either  “airplane”  or  “pilot”  in  the  title 
field: 

title:  (airplane  OR  pilot) 

The  following  search  returns  records  that  include  “airplane”  in  their  titles  or  “pilot”  in 
any  required  field: 

title:  airplane  OR  pilot 
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Two  or  more  fields  may  be  speeified  in  a  seareh.  The  following  seareh  returns  reeords 
that  inelude  “hazmat”  in  the  title  field  and  “training”  in  the  keyword  field. 


title:  hazmat  keyword:  training 
See  Seetion  B.2  for  detailed  information  on  field  names. 

B.2  Field  reference 

This  seetion  provides  a  eomplete  referenee  for  fields  that  are  searehable  in  the  ADL 
Registry. 

B.2.1  Non-contributor  fields 

Table  B.2  lists  in  alphabetieal  order  the  fields  that  are  not  related  to  speeific  contributor 
roles.  The  LOM  [4]  and  transaction  metadata  elements  to  which  the  fields  map  are 
explained  in  more  detail  in  Volume  3.  Contributor-related  fields  are  discussed  in 
Section  0. 

NOTE  -  Some  fields  in  Table  B.2,  even  though  they  can  be  used  in  searches,  should  not  be  used 
because  they  currently  allow  only  required  values  that  match  every  record  in  the  ADL  Registry. 
These  fields  are  included  for  completeness  and  indentified  in  the  table. 

Table  B.2  -  Non-contributor  field  reference 


Field 

Definition 

collection 

Identifies  an  object’s  grouping  or  category  of  usage.  The  vocabulary 
is  open.  Contributor-defined  values  may  be  provided  instead  of  or  in 
addition  to  the  recommended  value.  The  recommended  value  is: 

DOD 

Usage: 

collection:  (DOD  &  NAVSEA) 

LOM  mapping: 

/lorn/  classification/taxonPath/taxon/  entry/string 

NOTE  -  Searching  this  field  for  the  value  “DOD”  should  match  most  of  the 
records  in  the  ADL  Registry  because  the  value  is  recommended.  However, 
this  field  may  be  used  to  search  for  additional,  contributor-defined  values. 
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Field 

Definition 

competency 

A  contributor-defined  value  that  identifies  an  object’s  competency 
goal. 

Usage: 

competency:  “Some  competency” 

LOM  mapping: 

/lorn/  classification/taxonPath/taxon/  entry/string 

complieswith 

The  specification  or  standard  with  which  an  object  complies.  The 
allowed  values  are  : 

SCORM  2004  3rd  edition 

SCORM  2004  4th  edition 

SCORM  Version  1.2 

SIOOOD  V2.0 

SIOOOD  V2.1 

SIOOOD  V2.2 

SIOOOD  V2.3 

SIOOOD  V3.0 

SIOOOD  V4.0 

IEEE  1484.20.1-2007  RCD 

other 

none 

Usage: 

complies  with:  “SCORM  2004  4th  edition” 
complies  with:  other 

LOM  mapping: 

/lorn/  classification/taxonPath/taxon/  entry/string 

date 

The  date  an  object  was  contributed  to  the  ADE  Registry  in  the  form 
YYYYMMDD. 

Usage: 

date:  20071201 

date:  [20071201  TO  20071215] 
date:  {20071201  TO  20071215} 

LOM  mapping: 

/lom/lifeCycle/contribute/date 

NOTE  -  This  value  should  correspond  to  the  original  contribution  date  and 
should  not  be  updated  if  a  metadata  record  is  updated  (see  timeStamp  entry). 
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Field 

Definition 

description 

A  narrative  description  of  an  object. 

Usage: 

description:  airplane 
description:  “airplane  pilot” 

LOM  mapping: 

/lom/general/description/string 

distribution  restrictions 

Any  distribution  restrictions  associated  with  an  object  according  to 
DoDl  1322.20  or  DoDl  5230.24.  The  allowed  values  are: 

LR 

NR 

CP 

CG 

CD 

RD 

NF 

OT 

Distribution  Statement  A 

Distribution  Statement  B 

Distribution  Statement  C 

Distribution  Statement  D 

Distribution  Statement  E 

Distribution  Statement  F 

Distribution  Statement  X 

Usage: 

distribution  restrictions:  LR 

distribution  restrictions:  “Distribution  Statement  A” 

LOM  mapping: 

/lorn/  classification/taxonPath/taxon/  entry/string 

educationalobj  ective 

A  contributor-defined  value  that  identifies  an  object’s  educational 
objective. 

Usage: 

educational  objective:  “Some  objective” 

LOM  mapping: 

/lorn/  classification/taxonPath/taxon/  entry/string 
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Field 

Definition 

format 

A  list  of  MIME  types  for  files  present  in  an  object  or  the  value  “non¬ 
digital”.  Common  MIME  types  include: 

text/html  for  Web  pages 
text/plain  for  text  files 

application/msword  for  Microsoft  Word  documents 
application/pdf  for  PDF  documents 
image/jpeg  for  JPEG  images 
image/gif  for  GIF  images 

Usage: 

format:  text/htm 
format:  image/gif 

LOM  mapping: 

/lom/technical/format 

NOTE  -  MIME  types  are  a  standard  way  of  describing  file  formats  and  are 
reflected  by  file  extensions.  A  reference  for  MIME  type  names  is  available  at 
httD://www. w3schools.com/media/media  mimerefaso  151. 

keyword 

Descriptive  keywords  for  an  object. 

Usage: 

keyword:  airplane 
keyword:  “airplane  pilot” 

LOM  mapping: 

/lorn/  general/keyword/  string 

metadatalnstance 

Identifier 

A  metadata  instance  identifier.  Each  metadata  record  in  the  ADE 
Registry  is  assigned  a  unique  identifier. 

Usage: 

metadatalnstanceldentifier: 

100.3/MDcl50eca9afbbcb008bb83670b87dlfl41243974576628 

Transaction  metadata  mapping: 

/registryTransaction/transactionData/metadatalnstanceDescriptor/ 

cordraMetadata/metadatalnstanceldentifier 

NOTE  -  A  search  using  this  field  returns  the  single  metadata  record  that  has 
the  specified  identifier. 
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Field 

Definition 

metadatas  chema 

The  XML  schemas  used  to  define  the  metadata  for  an  object.  In 
addition  to  user-defined  values,  the  required  values  are: 

•  LOMvl.O 

•  ADL-Rvl.O 

Usage: 

metadataSchema:  LOMvl.O 

metadataSchema:  “ANSI/MEDBIQ  LO.  10. 1-2008” 

LOM  mapping: 

/lom/metaMetadata/metadataSchema 

NOTE  -  A  search  for  either  of  the  required  values  will  match  every  record  in 
the  ADL  Registry.  However,  this  field  may  be  used  to  search  for  other,  user- 
defined  values. 

objectldentifier 

A  unique  object  identifier.  Each  object  in  the  ADE  Registry  is 
assigned  a  unique  identifier  and  always  has  at  least  one  associated 
metadata  record. 

Usage: 

objectldentifier:  100.50. 18.10/cl50eca9afbbcb008bb83670b87dlfl4 

Transaction  metadata  mapping: 

/registryTransaction/transactionData/  obj  ectDescriptor/cordraObj  ect/ 
objectldentifier 

NOTE  -  A  search  using  this  field  returns  metadata  records  associated  with  a 
single  object  that  has  the  specified  identifier. 

optionalText 

Searches  all  optional  metadata  elements  that  are  not  required  in  a 
metadata  submission. 

Usage: 

optionaltext:  airplane 
optionaltext:  “airplane  pilot” 

LOM  mapping: 

None. 

NOTE  -  This  field  may  be  used  to  search  for  optional  metadata  that  an 
organization  is  known  to  include  in  its  submissions. 
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objecttype 

Identifies  the  type  of  an  object.  The  allowed  values  are: 

•  asset 

•  SCO 

•  aggregation 

•  other 

Usage: 

object  type:  aggregation 

LOM  mapping: 

/lorn/  classification/taxonPath/taxon/  entry/string 

purpose 

The  XML  schema  in  which  the  allowed  vocabulary  set  for  the  taxon 
field  is  defined  (see  taxon  entry).  The  value  of  the  purpose  field 
describes  the  metadata  record  itself,  not  the  object  that  the  record 
describes.  The  allowed  values  are: 

•  LOMvl.O 

•  ADL-Rvl.O 

Usage: 

purpose:  LOMvl.O 
purpose:  ADL-Rvl.O 

LOM  mapping: 

/lorn/  classification/purpose/source 

NOTE  -  This  field  should  not  be  used  in  a  search  at  this  time.  Searching  this 
field  for  one  or  both  of  the  two  allowed  values  will  match  every  record  in  the 
ADL  Registry  because  both  values  are  required.  Future  versions  of  the  ADL 
Registry  may  define  new  vocabulary  sets  for  the  taxon  field.  If  so,  additional 
values  for  the  purpose  field  will  be  introduced. 

repositoryldentifier 

A  unique  repository  identifier.  Each  repository  registered  with  the 

ADL  Registry  is  assigned  a  unique  identifier. 

Usage: 

repositoryldentifier:  100.5 1/jadlrepository 

Transaction  metadata  mapping: 

/registryTransaction/transactionData/communityObject/ 

repositoryldentifier 

NOTE  -  A  search  using  this  field  returns  only  metadata  records  associated 
with  a  single  repository  that  has  the  specified  identifier. 
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rights 

The  XML  schema  in  which  the  allowed  vocabulary  set  for  the 
rightsValue  field  is  defined  (see  rightsValue  entry).  The  value  of  this 
field  describes  the  metadata  record  itself,  not  the  object  that  the  record 
describes.  The  allowed  value  is: 

•  LOMvl.O 

Usage: 

rights:  LOMvl.O 

LOM  mapping: 

/lom/rights/copyrightAndOtherRestrictions/source 

NOTE  -  This  field  should  not  be  used  in  a  search  at  this  time.  Searching  this 
field  for  the  single  allowed  value  will  match  every  record  in  the  ADL 

Registry  because  the  value  is  required.  Future  versions  of  the  ADL  Registry 
may  define  new  vocabulary  sets  for  the  rightsValue  field.  If  so,  additional 
values  for  the  rights  field  will  be  introduced. 

rights  Value 

Specifies  whether  intellectual  property  restrictions  are  associated  with 
an  object.  The  allowed  values  are: 

•  yes 

•  no 

Usage: 

rightsValue:  yes 
rightsValue:  no 

LOM  mapping: 

/lom/rights/copyrightAndOtherRestrictions/value 

role 

The  XML  schema  in  which  the  allowed  vocabulary  set  for  the 
contributor  field  is  defined.  The  value  of  the  role  field  describes  the 
metadata  record  itself,  not  the  object  that  the  record  describes.  The 
allowed  values  are: 

•  ADL-Rv.lO 

•  LOMvl.O 

Usage: 

role:  LOMvl.O 

LOM  mapping: 

/lom/lifeCycle/contribute/role/source 
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securitylevel 

The  security  level  of  an  object.  The  allowed  value  is: 

unclassified 

Usage: 

security  level:  unclassified 

LOM  mapping: 

/lorn/  classification/taxonPath/taxon/  entry/string 

NOTE  -  This  field  should  not  be  used  as  part  of  a  search  at  this  time. 

Searching  this  field  for  the  single  allowed  value  will  match  every  record  in 
the  ADL  Registry  because  the  value  is  required.  Future  versions  of  the  ADL 
Registry  may  define  additional  values  for  this  field. 

status 

The  XML  schema  in  which  allowed  vocabulary  sets  for  the 
statusValue  field  are  defined  (see  statusValue  entry).  The  value  of  the 
status  field  describes  the  metadata  record  itself,  not  the  object  that  the 
record  describes.  The  allowed  values  are: 

ADL-Rvl.O 

LOMvl.O 

Usage: 

status:  ADL-Rvl.O 

LOM  mapping: 

/lom/lifeCycle/status/source 

status  Value 

The  life-cycle  status  of  an  object.  If  the  status  source  is  set  to  ADL- 
vl.O  (see  status  entry),  the  allowed  values  are: 

query  only 

proposed  development 

under  development 

development  or  acquisition  completed 

program  revision 

out  of  service 

program  terminated 

other 

If  the  status  source  is  set  to  LOMvl.O  (see  status  entry),  the  allowed 
values  are: 

draft 

final 

revised 

unavailable 

Usage: 

statusValue:  “under  developmenf  ’ 
statusValue:  final 
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LOM  mapping: 

/lom/lifeCycle/status/value 

taxon 

Information  that  helps  classify  an  object  within  a  categorization 
scheme.  The  allowed  values  for  this  field  depend  on  the  source  and 
value  provided  within  the  purpose  field.  Possible  values  include: 

ADL/DOD  Object  Category  Taxonomy 

ADL/DOD  Compliance  Taxonomy 

ADL/DOD  Distribution  Taxonomy 

ADL/DOD  Object  Type  Taxonomy 

ADL/DOD  Security  Taxonomy 

A  contributor-defined  competency  taxonomy 

A  contributor-defined  educational  objective  taxonomy 

Usage: 

taxon:  “ADL/DOD  Distribution  Taxonomy” 
taxon:  “some  competency  taxonomy” 

LOM  mapping: 

/lom/classification/taxonPath/source/string 

NOTE  -  Searching  this  field  for  one  of  the  predefined  values  will  match 
every  record  in  the  ADL  Registry  because  all  five  values  are  required. 
However,  additional,  contributor-defined  values  for  competencies  and 
educational  objectives  are  allowed  for  this  field. 

text 

Searches  all  mandatory  metadata  elements  when  no  other  field  is 
specified  in  a  search. 

Usage: 

text:  airplane 
text:  “airplane  pilot” 

LOM  mapping: 

None. 

NOTE  -  Because  this  field  is  searched  by  default,  it  is  unnecessary  to  specify 
the  field  name  in  a  search. 

time  Stamp 

The  date  a  metadata  submission  was  made  in  the  form 

YYYYMMDD.  This  value  is  updated  each  time  the  associated 
metadata  record  is  updated. 

Usage: 

timeStamp:  20071201 

Transaction  metadata  mapping: 

/registryTransaction/transactionData/timeStamp 

NOTE  -  This  field  can  be  used  to  search  for  updated  metadata  records.  The 
date  field  should  be  used  to  search  for  objects  by  original  contribution  date. 
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title 

A  descriptive  title  for  an  object. 

Usage: 

title:  airplane 
title:  “airplane  pilot” 

LOM  mapping: 

/lom/general/title/string 

version 

A  developer-defined  version  number  for  an  object.  The  developer 
may  specify  any  value  that  meets  his  or  her  organizational 
requirements. 

Usage: 

version:  1.0 
version:  final 

LOM  mapping: 

/lom/lifeCycle/version/string 

B.2.2  Contributor-related  fields 

Table  B.3  includes  the  fields  that  are  related  to  various  contributor  roles,  such  as  author 
and  object  provider.  Only  the  author  field  is  required  to  have  a  value.  All  the  fields  map 
to  /lom/lifeCycle/contribute/entity. 

Table  B.3  -  Contributor-related  field  reference 


Field 

Description 

author 

Searches  for  objects  by  author. 

Usage: 

author:  “ADL  Co-Lab” 
author:  “Joe  Author” 

content_provider 

Searches  for  objects  by  content  provider. 

Usage: 

content_provider:  “ADL  Co-Lab” 
content_provider:  “Joe  Provider” 

NOTE  -  This  field  is  present  for  backwards  compatibility.  The 
object_provider  field  is  preferred.  To  ensure  that  all  records  for  a  specific 
provider  are  returned,  include  both  object_provider  and  content_provider  in 
the  search. 
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Description 

editor 

Searches  for  objects  by  editor. 

Usage: 

editor:  “ADL  Co-Lab” 
editor:  “Joe  Editor” 

educational  validator 

Searches  for  objects  by  educational  validator. 

Usage: 

educational  validator:  “ADL  Co-Lab” 
educational  validator:  “Joe  Validator” 

graphicaldesigner 

Searches  objects  by  graphical  designer. 

Usage: 

graphical  designer:  “ADL  Co-Lab” 
graphical  designer:  “Joe  Artist” 

initiator 

Searches  for  objects  by  project  initiator. 

Usage: 

initiator:  “ADL  Co-Lab” 
initiator:  “Joe  Initiator” 

instructional  designer 

Searches  for  objects  by  instructional  designer. 

Usage: 

instructional  designer:  “Joint  ADL  Co-Lab” 
instructional  designer:  “Joe  ISD” 

object_provider 

Searches  for  objects  by  object  provider. 

Usage: 

object_provider:  “ADL  Co-Lab” 
object_provider:  “Joe  Provider” 

NOTE  -  This  field  has  replaced  content_provider  in  current 
recommendations  for  registering  objects.  To  ensure  that  all  records  for  a 
specific  provider  are  returned,  include  both  object_provider  and 
content_provider  in  the  search. 

publisher 

Searches  for  objects  by  publisher. 

Usage: 

publisher:  “ADL  Co-Lab” 
publisher:  “Joe  Publisher” 

script  writer 

Searches  for  objects  by  script  writer. 

Usage: 

script  writer:  “ADL  Co-Lab” 
script  writer:  “Joe  Writer” 
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Field 

Description 

subject  matter  expert 

Searches  for  objects  by  subject  matter  expert. 

Usage: 

subject  matter  expert:  “ADL  Co-Lab” 
subject  matter  expert:  “Joe  Expert” 

technical  implementer 

Searches  for  objects  by  technical  implementer. 

Usage: 

technical  implementer:  “ADL  Co-Lab” 
technical  implementer:  “Joe  Implementer” 

technical  validator 

Searches  for  objects  by  technical  validator. 

Usage: 

technical  validator:  “ADL  Co-Lab” 
technical  validator:  “Joe  Validator” 

terminator 

Searching  for  objects  by  project  terminator. 

Usage: 

terminator:  “ADL  Co-Lab” 
terminator:  “Joe  Terminator” 

validator 

Searches  for  objects  by  validator. 

Usage: 

validator:  “ADL  Co-Lab” 
validator:  “Joe  Validator” 
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